[SIPForum-discussion] Need Info - UAC behavior

Tue Jan 27 20:27:16 UTC 2009

Hi,

SDP does not specify the allowed value for this parameter but says that for
RTP/AVT this is the payload type number. Now if you will have the value of
12345 in the offer, once you receive the RTP stream you will not know what
codec it is since the PT field in the RTP header is 7 bits for example take
the following off and have the answer accept both. Now when you get the
actual stream you cannot know which one it is since you cannot map the
payload type umber

m=audio 6000 RTP/AVP 12345 45321

 a=rtpmap:12345 PCMA/8000

a=rtpmap:45321 PCMU/8000

Roni Even

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Moshe Ostrovsky
Sent: Tuesday, January 27, 2009 8:58 AM
To: rajeshk.r at samsung.com
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Need Info - UAC behavior

Hi Rajesh.

We can support the following media description:

m=audio 6000 RTP/AVP 12345

 a=rtpmap:12345 PCMA/8000

It does not contradict with the SDP standard, am I right?

Thanks, Moshe.

From: RAJESH KUMAR RAJU [mailto:rajeshk.r at samsung.com] 
Sent: Tuesday, January 27, 2009 7:05 AM
To: Moshe Ostrovsky
Cc: Gowthaman Desingh; discussion at sipforum.org
Subject: Re: RE: [SIPForum-discussion] Need Info - UAC behavior

Hi , 

Kindly find out ur sip stack follows which rfc . whether it is following rfc
4566 or RFC 3551 .

Thanks and Regards

Rajesh

------- Original Message -------
Sender : Moshe Ostrovsky<mosheo at radvision.com>
Date : Jan 25, 2009 05:02 (GMT+09:00)
Title : RE: [SIPForum-discussion] Need Info - UAC behavior

Hi All.

Regarding Payload type number, can you please point to the RFC part that
sets the range validity restrictions?

What I could see in RFC 4566 is that there is no restriction. 

According to RFC 3551 - the range is 0-127.

What happens if I need to define dynamic codec beyond 127?

Thanks.

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of RAJESH KUMAR RAJU
Sent: Thursday, January 22, 2009 7:08 AM
To: Gowthaman Desingh
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Need Info - UAC behavior

Dear Gowtham, 

*m=audio 6000 RTP/AVP 12345*

 *a=rtpmap:8 PCMA/8000*

Any Objective behind doing this , because as per rfc  , i have never seen
any one doing like this . and 12345 must be a valid defined 

Payliad type and also the Payload type number must be in the defined range .
u can check the rfc .

------- Original Message -------
Sender : Gowthaman Desingh<gowtham_dgm at rediffmail.com>
Date : Jan 21, 2009 15:31 (GMT+09:00)
Title : [SIPForum-discussion] Need Info - UAC behavior

Hi All,
  I would like to know the expected behavior of the UAC in the below
mentioned scenario.

Setup:
        |SIP Phone | -------- |sipp| 
    I have connected a SIP phone back to back with SIPP.

1. I send an INVITE request from the SIP Phone to the sipp with the below
mentioned SDP offer.
**********************************
v=0
o=SIPUA 22986 0 IN IP4 9.7.40.253
s=SIP Call
t=0 0
m=audio 19570 RTP/AVP 0 8 18 102 9 101
c=IN IP4 9.7.40.253
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:102 L16/16000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
**********************************

2. Accept the call from sipp by sending 200 OK.
  In the 200 OK sent by the sipp, I send the below mentioned SDP answer. The
payload number mentioned in the m=line is "12345"(which is invalid). But the
payload number mentioned in the attribute is valid (8 - PCMA). 
**********************************
v=0
o=user1 53655765 2353687637 IN IP4 9.7.40.50
s=-
t=0 0
a=recvonly
c=IN IP4 9.7.40.50
*m=audio 6000 RTP/AVP 12345*
c=IN IP4 9.7.40.50
*a=rtpmap:8 PCMA/8000*
a=sendonly
*********************************** 

My phone is sending 200 OK followed by BYE to terminate the call. Is that a
valid behavior. 

Thanks,
Gowthaman D

u can reach me on my mobile @ +919886625873

<http://adworks.rediff.com/cgi-bin/AdWorks/click.cgi/www.rediff.com/signatur
e-home.htm/1050715198 at Middle5/2703345_2674874/2678496/1?PARTNER=3&OAS_QUERY=
null> Image removed by sender. Tata Tea

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090127/2ecb7a05/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://sipforum.org/pipermail/discussion/attachments/20090127/2ecb7a05/attachment.jpg>