headers
Sungbum Lim | 24 May 2013 07:47
Picon

commercial SIP stack/library.

Hello..

I am planning to develop an Android app.

please suggest me a good commercial SIP stack/library.

Thanks,
SB
Permalink | Reply | 1 comment |
headers
Olle E. Johansson | 21 May 2013 11:22
Gravatar

Re: Query for "received" parameter in top Via header


21 maj 2013 kl. 11:19 skrev isshed <isshed.sip <at> gmail.com>:

> Anand
> 
> the received parameter is added by your own stack(one who received the
> request). It contains real IP from where the packet is received. In case of
> NAT it will be NAT IP.
That seems like a broken NAT. If you are inside of a NAT and receive a message
from the outside, the NAT should not change the sender's address, right?

/O
> 
> On Tue, May 21, 2013 at 2:35 PM, ANAND KUMAR <ss1439anand <at> yahoo.co.in>wrote:
> 
>> Section 18.2.2 Sending Responses (For servers) of rfc3261 says:
>> 
>> if the top Via has a "received" parameter, the response MUST be sent to
>> the address in the "received" parameter, using the port indicated in the
>> "sent-by" value, or using port 5060 if none is specified explicitly. If
>> this fails, for example, elicits an ICMP "port unreachable" response
>> 
>> 
>> Now assume a Client (which is behind a proxy and there may be a NAT
>> between the client and proxy) which is in a 2-way call receives BYE for
>> this call (I am assuming UAS behaviour by the Client) having top Via header
>> with received parameter (having ip address which is not same as that of the
>> proxy).
>> 
>> My query:
(Continue reading)

Permalink | Reply | 0 comments |
headers
ANAND KUMAR | 21 May 2013 11:05
Picon
Favicon

Query for "received" parameter in top Via header

Section 18.2.2 Sending Responses (For servers) of rfc3261 says:
 
if the top Via has a "received" parameter, the response MUST be sent to the address in the "received"
parameter, using the port indicated in the "sent-by" value, or using port 5060 if none is specified
explicitly. If this fails, for example, elicits an ICMP "port unreachable" response
 
 
Now assume a Client (which is behind a proxy and there may be a NAT between the client and proxy) which is in a
2-way call receives BYE for this call (I am assuming UAS behaviour by the Client) having top Via header with
received parameter (having ip address which is not same as that of the proxy). 
 
My query:
 
1. Then should this Client send 200 OK of BYE to this ip address (received)? 
2. Will this scenario ever happen for the client (also assume a NAT between the Client and proxy for the
purpose of analysis) in realtime?
3. If this scenario will never happen in real time then does the RFC statement(written above) stands valid
for this Client (UAS in this case)?
 
Please correct my understanding if it is wrong somewhere.
 
 
Thanks in advance
Anand Kumar
Permalink | Reply | 2 comments |
headers
Milton Sanchez | 20 May 2013 21:49
Picon

sip over TCP

Hello, can someone please point me to the right direccion on finding some
infomarction/tutorial about SIP over TCP.

regards
Milton
Permalink | Reply | 7 comments |
headers
Priya Arya | 20 May 2013 20:12
Favicon

Query regarding session timer behaviour in SIP Stack

Hi All,

I have certain queries about the session timer behaviour in the SIP Stack.
The scenario is as follows :

         SIP Stack                                                                               N/w

At T0s
            INVITE  -------------------------------------------------------------------------------->
                                            (having SE=600 &Min-SE = 600 )

            100 Trying <---------------------------------------------------------------------------
            180 Ringing <-------------------------------------------------------------------------
            200 OK <-------------------------------------------------------------------------------
                                 (having Require:timer,SE=600,refresher=uas)
            ACK   ---------------------------------------------------------------------------------->

            <---------------------------------Call Connected --------------------------------->

At this point the Call is connected and the session timer is started by SIP Stack when 200 OK from the Network
is received by the SIP Stack.
After this, SIP Stack sends out a Re-INVITE with as the new offer(as the version number in the o-line is
incremented here).

At T0+8s
             INVITE  --------------------------------------------------------------------------->
               (Version number in o-line of Re-INVITE SDP is incremented by 1)

             200 OK <-------------------------------------------------------------------------------
                                          (having SE=19200,refresher=uas)
(Continue reading)

Permalink | Reply | 3 comments |
headers
ANAND KUMAR | 20 May 2013 12:53
Picon
Favicon

Query for method name in Request URI


Hi,
I have a query for method available in Request URI.
According to rfc 3261 section 19.1.5
"If the URI contains a method parameter, its value MUST be used as the method of the request." 
Now suppose the UAC receives 302 Moved Temporary with Contact like 
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
Doest that mean the UAC need to send REGISTER request to sip:biloxi.com ?
If not then what is the meaning of this method name in the Request URI?

Thanks & Regards
Anand Kumar
Permalink | Reply | 1 comment |
headers
Aman | 20 May 2013 12:37
Picon

FMT are mandatory in the Media Descriptions ("m=") line

Hi All,

Looking for the views on, if the media format description <fmt> are
mandatory to mention in the media descriptions (m=) line of SDPs.

RFC4566 section 8.2.3 says,

...

RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST
use the payload type number as their "fmt" value.
...

how a state-full proxy/SBC should react, who is receiving the m= line
having no fmt values like,

|v=0
|o=ABC-SIP 2000 1000 IN IP4 192.168.180.10
|s=SIP Call
|c=IN IP4 192.168.180.10
|t=0 0
|m=audio 25218 RTP/AVP
|a=sendrecv
|a=rtpmap:0 PCMU/8000
|a=ptime:20

Cheers,
Aman
Permalink | Reply | 2 comments |
headers
Yang Hong | 17 May 2013 18:59
Picon
Favicon

Survey on SIP overload control algorithms

Hello Folks.

SIP faces with overload issue recently due to its popularity.  Build-in overload mechanism cannot prevent
overload effectively. Therefore, IETF SIP Overload Control (soc) Working Group works on IETF RFC "SIP
Overload Control" currently.
http://tools.ietf.org/html/draft-ietf-soc-overload-control-12

A survey on SIP overload control algorithms (including IETF RFC "SIP Overload Control") can be downloaded
from the following link free of charge.
Y. Hong, C. Huang, and J. Yan, “A Comparative Study of SIP Overload Control Algorithms,"Network and
Traffic Engineering in Emerging Distributed Computing Applications, Edited by J. Abawajy, M. Pathan,
M. Rahman, A.K. Pathan, and M.M. Deris, IGI Global, 2012, pp. 1-20.
http://www.researchgate.net/publication/231609451_A_Comparative_Study_of_SIP_Overload_Control_Algorithms
http://arxiv.org/abs/1210.1505
http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67496

Control theorectic approaches have been applied to model the interactions between an overloaded SIP
server and its upstream servers as a feedback control system in two different scenarios - redundant
retransmission ratio control and round trip delay control (IEEE Globecom 2010 and ICC 2011).

"Mitigating SIP Overload Using a Control-Theoretic Approach" IEEE Globecom 2010
http://www.researchgate.net/publication/221284946_Mitigating_SIP_Overload_Using_a_Control-Theoretic_Approach
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5683124&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5683124

Implementation of implicit SIP overload control in the real system
"An Efficient Earthquake Early Warning Message Delivery Algorithm Using an in Time Control-Theoretic Approach"
http://link.springer.com/chapter/10.1007%2F978-3-642-23641-9_15#
http://www.ipv6.org.tw/docu/elearning8_2011/1010004798p_3-7.pdf  

 "Design Of A PI Rate Controller for Mitigating SIP Overload" IEEE ICC 2011
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yulian Oifa | 15 May 2013 22:04
Picon

Clarification/recommendation needed on sip protocol

Hello to all.
I am working with jain sip based software and having the following issue:
while proxy sends sip MESSAGE request to UA transaction can be timed out
but message still delivered.
This may happen on any kind of channel due to network slow response,and on
tls/tcp channel due
to connection oriented nature of channel.
in case of tls/tcp message is stored in socket buffer and socket tries to
resend this packet.
When first time it tries to send the packet destination is not reachable
due to firewall/nat machine on the way to UA which removed the nat hole.
After some time UA will send either keepalive or some sip request and this
will cause nat hole to be reopened.
Since proxy socket received the data from UA it will resend all the data it
has for him in buffer and message will be delivered.
UA of course will send 200 OK for the message , but since transaction timed
out this response can not be send further.

Since B2BUA will try to send same sip message later on , UA will end up
with 2 or more duplicate messages received.
Similar situation may happen with any NON INVITE transaction.
Is there some rfc or some recommendation how this issue can be resolved?

Thanks and best regards
Yulian Oifa
Sipme LTD
israel
Permalink | Reply | 1 comment |
headers
Sumant Gupta | 14 May 2013 12:25
Picon

Require header in ACK request

 Hi All,

As per 3261

"An ACK request for a 2xx response MUST contain only those Require and
Proxy-Require values that were present in the initial request".

 As per table 2 (rfc 3261) require header is not applicable in ACK request.

Does it serve any purpose if we send Require/Proxy-Require header in the
ACK request?
Any reason why it is mentioned in RFC as older posts on this forum does not
provide any concrete answer?

Regards
Sumant
Permalink | Reply | 1 comment |
headers
Gaurav Gupta | 14 May 2013 08:25
Favicon

Query for Out of dialod Notify

Hi,

Subscribe creates a dialog in SIP, then why client can receive out of dialog notify

Thanks
Gaurav Gupta

===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
Permalink | Reply | 4 comments |

Gmane