|
Hello,
Yes, i do agree with you that when both the
parties support codec 3 and 5, the RTP payload also would be either 3 or
5
But i wanted to know whether the offeror could
still send an ACK with sdp details by selecting
one of the coders.
Because i did come across some statements saying
ACK should not be sent with sdp details if the
offer is already sent in an INVITE.
Is the following INVITE-200OK-ACK
handshake against the RFC 3264 implementation
OFFEROR (SDP details in INVITE)
v= 0
o= A 1464112736 1464112736 IN
IP4 151.209.33.190
s=Calling
c=IN IP4
pgs-477
t=0 0
m=audio 2074 RTP/AVP 0 3
5
a=rtpmap:0
PCMU/8000
a=rtpmap:3
GSM/4000
a=rtpmap:5
ADPCM/4000
ANSWERER(SDP details in 200 OK
)
v= 0
o= B1464112736 1464112736 IN
IP4 151.209.33.194
s=Answering the
call
c=IN IP4
pgs-451
t=0 0
m=audio 2074 RTP/AVP 3
5
a=rtpmap:3
GSM/4000
a=rtpmap:5
ADPCM/4000
OFFEROR (SDP details in ACK)
v= 0
o= A 1464112736 1464112736 IN
IP4 151.209.33.190
s=Calling
c=IN IP4
pgs-477
t=0 0
m=audio 2074 RTP/AVP 3
a=rtpmap:3
GSM/4000
If the above handshake is not
allowed, then looking into the payload type in the RTP header is the the only
way to
find out for the negotiated codec
?
Thanks,
Prabha N
----- Original Message -----
Sent: Monday, December 15, 2003 10:37
AM
Subject: RE: [Sip-implementors]
Offer-answer queries
-----Original
Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prabha
Sent: Friday, December 12,
2003 6:41
PM
To: Ranjit Avasarala (WT01 - TELECOM
& INTER-NETWORKING SOLUTIONS); [EMAIL PROTECTED]
Subject: Re: [Sip-implementors]
Offer-answer queries
Thanks for the response. But
i am still not clear.
Here 200 Ok has been sent
with codecs 3 and 5. It means to say that he is supporting both 3 and
5.
Now how does an offeror identify
the final negotiated codec without seeing the payload type in
If 200 OK would have come with one
coder, then it is clear fto the offeror regarding the accepted
codec
[ABN] the
result of the offer/answer negotiation is not the content of the data carried
in the message but the agreed upon set of encodings supported by both the
parties�
If both the
parties support codec 3 & 5 obviously the RTP payload could be one of the
two offers carried in the initial offer�
Please can you give some more
inputs on this.
----- Original Message -----
Sent:
Friday, December 12,
2003 5:15
PM
Subject: RE:
[Sip-implementors] Offer-answer queries
The accepted codec gets reflectd in 200 OK. so there is no need to send
negotiated codecs in ACK. If no offer is sent in INVITE by caller, then the
callee send his offer in 200 OK and the negotiated codec should be sent by
caller in ACK
Thanks &
Regards
Ranjit
Wipro
Technologies
E-City,
Bangalore
Ph: 8520408/16
extn: 2173
-----Original
Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prabha
Sent: Friday, December
12, 2003 4:42
PM
To:
[EMAIL PROTECTED]
Cc: Jonathan Rosenberg
Subject: [Sip-implementors]
Offer-answer queries
I have a question regarding
the SDP part of the Invite request.
suppose user agent
"A" wants to talk to user agent "B", he sends a INVITE
request to B. the
SDP part of the invite request is as follows,
v= 0
o= A 1464112736
1464112736 IN IP4 151.209.33.190
s=Calling
c=IN IP4
pgs-477
t=0 0
m=audio 2074 RTP/AVP 0 3
5
a=rtpmap:0
PCMU/8000
a=rtpmap:3
GSM/4000
a=rtpmap:5
ADPCM/4000
If user agent accepts
the request and agrees to talk to user agent A, he
sends a OK response with
SDP as followed.
v= 0
o= B1464112736
1464112736 IN IP4 151.209.33.194
s=Answering the
call
c=IN IP4
pgs-451
t=0 0
m=audio 2074
RTP/AVP 3 5
a=rtpmap:3
GSM/4000
a=rtpmap:5
ADPCM/4000
now why can�t the user
agent A send an ACK by selecting one of the coders specified in answer
AS
mentioned
below ?
v= 0
o= A 1464112736
1464112736 IN IP4 151.209.33.190
s=Calling
c=IN IP4
pgs-477
t=0 0
m=audio 2074
RTP/AVP 3
a=rtpmap:3
GSM/4000
than analyzing the payload
type (PT) header field in the RTP Packet.
Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. |
_______________________________________________
Sip-implementors
mailing
list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.
|
|
