headers
Yong Xin | 1 Oct 2010 17:37
Favicon

loopback address 127.0.0.1 in SDP

Hi,

Following is an example of SDP that uses 127.0.0.1 as the media address.

v=0
o=twinkle 1121345221 983211842 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 8000 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=ptime:20

Does anyone know what does it mean?  Should it be treated as the
blackhole address "0.0.0.0"? I looked RFC 3264 (offer/answer model) but
could not find an answer.

Thanks,
Yong
Permalink | Reply | 1 comment |
headers
Worley, Dale R (Dale | 1 Oct 2010 17:39
Favicon

Re: loopback address 127.0.0.1 in SDP

________________________________________
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Yong 

Following is an example of SDP that uses 127.0.0.1 as the media address.
_______________________________________________

It was probably sent in error.  However, two SIP elements resident on the same host could use 127.0.0.1 as the
media listening address.

Dale
Permalink | Reply | 0 comments |
headers
Rashid Shakil | 1 Oct 2010 21:33
Picon
Favicon

Question about significance of header (Supported: timer, 100rel)

 
Greetings,
 
Few quick questions regarding header "Supported: timer,100rel ". What is the significance of this
header within INVITE  and how it affect voice calls. I also noticed "PRACK" been send and receive if
both peering partner (media gateway) and SIP end points has 100rel enabled. Thanks ...
 
Supported: timer,100rel
 
- Rashid Shakil
Permalink | Reply | 2 comments |
headers
Worley, Dale R (Dale | 2 Oct 2010 00:02
Favicon

Re: sdp missing m line

________________________________________
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Paul Kyzivat [pkyzivat <at> cisco.com]

If so, then it has given the UAS few options.
The UAS can answer with an SDP containing no m-lines, and thus establish
a connection with no media.

OR, the UAS can return an error, such as 415, if it doesn't want to
participate in a call with no media.

I think you will find many/most audio UAs will probably return 415 or
some other error. It would be more forgiving of them to accept the call
and just treat it as if on hold for whatever media they have.
_______________________________________________

Beware that 415 is not the correct error response for this -- 415 means that the UA cannot understand the
media type of the body of the INVITE (which will be application/sdp).  Response 488 is used to say that the
characteristics of the media described in the SDP body are unacceptable.

Dale
Permalink | Reply | 2 comments |
headers
Worley, Dale R (Dale | 2 Oct 2010 00:35
Favicon

Re: SRTP

________________________________________
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Amarnath Kanchivanam [ykamarnath.sip <at> gmail.com]

Can anyone provide quick reference for key generation (master key)
algorithms?
_______________________________________________

RFC 4086 "Randomness Requirements for Security" provides useful information on generating random keys.

The "/dev/random" device on some systems provides quality random information.

Dale
Permalink | Reply | 1 comment |
headers
Worley, Dale R (Dale | 2 Oct 2010 00:38
Favicon

Re: Gateway Behavior when it receives a non-2xx (> 299) response with Content Type that it does not understand

In most circumstances, there is no need for the gateway to understand the response body.  So it should pass
the body through without modification.

However, if the gateway requires to understand the response body, it should add an Accept header to all
outgoing requests that restrict the responses to use content-types that it does understand.

If the UAS sends a response containing a body that the gateway does not understand, and there is a security
requirement that the gateway must understand the body, probably the best course of action is for the
gateway to remove the body and pass the rest of the response toward the UAC.  In almost all cases, the sender
of the request will process the response correctly (as there are no defined uses for non-SDP bodies for
failure responses).

Dale
Permalink | Reply | 0 comments |
headers
Maddipatla, Maheswara Rao (Mahesh | 2 Oct 2010 04:55
Favicon

Re: Question about significance of header(Supported: timer, 100rel)

Hi Rashid,

The Supported header field contains a list of option tags (timer,100rel,replaces,histinfo,join
...)that are understood by the UAC or UAS .

If a UAC wants to inform UAS about his capability of supporting/exchanging SIP extensions it will add those
in the Supported header and sends in the INVITE message .Supported header doesn't have impact on the call
since UAC doesn't insist UAS and its optional as well. Where as Require: header insists UAS and It becomes
mandatory for other party to respond .

If 100rel is enabled on both ends either calling or called party can include Supported :100rel or Required :
100rel in INVITE or subsequent 1xx message to show that it supports PRACK messages .Refer rfc3262 for
PRACK .

Thanks
Mahesh Maddipatla

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Rashid Shakil
Sent: Saturday, October 02, 2010 1:03 AM
To: sip-implementors <at> lists.cs.columbia.edu
Subject: [Sip-implementors] Question about significance of header(Supported: timer, 100rel)

 
Greetings,
 
Few quick questions regarding header "Supported: timer,100rel ". What is the significance of this
header within INVITE  and how it affect voice calls. I also noticed "PRACK" been send and receive if
both peering partner (media gateway) and SIP end points has 100rel enabled. Thanks ...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kyzivat | 2 Oct 2010 06:42
Picon
Favicon

Re: sdp missing m line

Sorry about that. I remembered the wrong number.

	Thanks,
	Paul

On 10/1/2010 6:02 PM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: sip-implementors-bounces <at> lists.cs.columbia.edu
[sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Paul Kyzivat [pkyzivat <at> cisco.com]
>
> If so, then it has given the UAS few options.
> The UAS can answer with an SDP containing no m-lines, and thus establish
> a connection with no media.
>
> OR, the UAS can return an error, such as 415, if it doesn't want to
> participate in a call with no media.
>
> I think you will find many/most audio UAs will probably return 415 or
> some other error. It would be more forgiving of them to accept the call
> and just treat it as if on hold for whatever media they have.
> _______________________________________________
>
>
> Beware that 415 is not the correct error response for this -- 415 means that the UA cannot understand the
media type of the body of the INVITE (which will be application/sdp).  Response 488 is used to say that the
characteristics of the media described in the SDP body are unacceptable.
>
> Dale
>
> _______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
AGRAWAL, VINEET (VINEET | 4 Oct 2010 09:50
Favicon

Update time out

Hi All,
          I am executing the SIP to Mobile call. The complete scenario is as below.
             SIP(UAC)                                    SWITCH                        MS

-------------->
INVITE with SDP(precondition not met)                               ---------------->
                                                                         PAGING
                                                                    ---------------->
                                                                         SETUP

<---------------
  183(Session Progress)
---------------->
   Prack
<---------------
   200OK(Prack)

Now Switch is waiting for UPDATE from SIP(UAC) for preconditions to be met. In my Case UAC is not sending the
UPDATE msg.
I want to ask is there any timer for UPDATE on UAS forreceiving UPDATE so that it can release the call, because
here the resources of SIP(UAC) are not getting released till 18 minutes.
18 minutes is so much long time for releasing the sip resources.
Is it right be behavior? Or resources should release after a certain time period(timer) when UPDATE is not
received .

Thanks,
Vineet
Permalink | Reply | 3 comments |
headers
Rashid Shakil | 4 Oct 2010 14:26
Picon
Favicon

Re: Question about significance of header(Supported: timer, 100rel)

Mahesh,
 
Thanks for the detailed response, very helpful ...

--- On Fri, 10/1/10, Maddipatla, Maheswara Rao (Mahesh) <mmaddipatla <at> avaya.com> wrote:

From: Maddipatla, Maheswara Rao (Mahesh) <mmaddipatla <at> avaya.com>
Subject: RE: [Sip-implementors] Question about significance of header(Supported: timer, 100rel)
To: "Rashid Shakil" <rashidshakil <at> yahoo.com>, sip-implementors <at> lists.cs.columbia.edu
Date: Friday, October 1, 2010, 10:55 PM

Hi Rashid,

The Supported header field contains a list of option tags (timer,100rel,replaces,histinfo,join
...)that are understood by the UAC or UAS .

If a UAC wants to inform UAS about his capability of supporting/exchanging SIP extensions it will add those
in the Supported header and sends in the INVITE message .Supported header doesn't have impact on the call
since UAC doesn't insist UAS and its optional as well. Where as Require: header insists UAS and It becomes
mandatory for other party to respond .

If 100rel is enabled on both ends either calling or called party can include Supported :100rel or Required :
100rel in INVITE or subsequent 1xx message to show that it supports PRACK messages .Refer rfc3262 for
PRACK .

Thanks
Mahesh Maddipatla

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
(Continue reading)

Permalink | Reply | 0 comments |

Gmane