[SIPForum-discussion] Early Media

Siva M-Q16748 sivam at motorola.com
Fri Apr 20 07:44:55 UTC 2007


Hi Santosh
 
This is the scenario
 
A calls ( throgh a B2BUA AS) B

B doesnot answer

Application Server sends INVITE to Media Server Application Server sends
the SDP info he got from Media Server to A in the 183 message A gets a
Music played by media Server Now Application server forwards the call to
C If C answers , A should get the SDP info of C ( I thought it would be
sent in 200 OK )

 
Siva M 
 

________________________________

From: santosh patra [mailto:skp10_9559 at yahoo.co.in] 
Sent: Friday, April 20, 2007 1:09 PM
To: Siva M-Q16748; Robert Mansfield; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] Early Media


Hello Siva

As far as I understand, Early media one such type of featuer or
functionaly of UA/AS/gateway. Early Media means There will some ringtone
played by Gateway or local ringtone generated by UAC followed by
Alert-Info Header..Before 200 OK/ Final response.and I don't know why
you need 183 "Session Progress" responce for this early Media....And its
used in SIP-ISUP interworking cases ACM in SS7 message same to 183
"Session Progress"  in SIP....May be I ma missing something here the
usage of 183 Response...Please let me know.

As far your question concerns, 183 is a 1xx Provisional response which
doesn't contain SDP part  and SDP part comes in Offer/Answer model which
one should be negotiated between two end points. And I believe that 183
response is not being used by any Endpoint, rather it would be sent by
stateful proxy/Gateway/AS...I don't know in which case 183 session
progress has SDP, If you have any valid scenarion then just let me
know.200 OK is considered as part of Offer/Answer model which one should
be sent by Callee his SDP capabilities....

Please correct me If I am wrong.

Cheers
Santosh


----- Original Message ----
From: Siva M-Q16748 <sivam at motorola.com>
To: Robert Mansfield <RJM at Redwoodtech.com>; discussion at sipforum.org
Sent: Friday, 20 April, 2007 10:36:01 AM
Subject: Re: [SIPForum-discussion] Early Media



Hi 

Would anybody be able to point out any Logical Reason why a 183 and 200
should not have same SDP ??

May be some scenario in which it creates issues ..

I hope there should be a Logical reason why RFC says so ..

Siva M 

-----Original Message-----
From: Robert Mansfield [mailto:RJM at Redwoodtech.com] 
Sent: Thursday, April 19, 2007 2:55 PM
To: Siva M-Q16748
Subject: RE: [SIPForum-discussion] Early Media

Siva,

If the use of early media is in the 'Gateway' model then I believe the
SDP descriptor in the 183 and 200 will be the same.

The scenario you describe is more akin to the Application Server model
(both models described in RFC 3960).

"Application Server sends the SDP info he got from Media Server to A in
the
183 message A gets a Music played by media"-In this case the B2BUA AS
could make use of the 'early-session' extension tag in the
'Content-Disposition'
header. This allows for the establishment of an early session with a
descriptor that is different from the SDP returned in the 200 OK.

"Server Now Application server forwards the call to C If C answers , A
should get the SDP info of C ( I thought it would be sent in 200 OK )"
Ok so now A needs to talk to C. The SDP descriptor is different and
represents the normal session represented by the INVITE/200/ACK.

I only have experience of this RFC in terms of the GATEWAY model so what
I'm not staking my life on the accuracy of this explanation however I
would be interested in your thoughts from RFC 3960 Application Server
model.

Hope this helps,

Rob.

-----Original Message-----
From: Siva M-Q16748 [mailto:sivam at motorola.com]
Sent: 19 April 2007 09:56
To: Robert Mansfield; discussion at sipforum.org
Subject: RE: [SIPForum-discussion] Early Media


Hi

If the 183 and 200 OK should have same SDP . How does the following
scenario
work ?? 

A calls ( throgh a B2BUA AS) B
B doesnot answer
Application Server sends INVITE to Media Server
Application Server sends the SDP info he got from Media Server to A in
the
183 message A gets a Music played by media Server Now Application server
forwards the call to C If C answers , A should get the SDP info of C ( I
thought it would be sent in 200 OK )

If 200 OK sent to A should have the same SDP as that of 183 , How can A
and
C talk in this case ..

Thanks
Siva M 

-----Original Message-----
From: Robert Mansfield [mailto:RJM at Redwoodtech.com] 
Sent: Thursday, April 19, 2007 1:54 PM
To: Siva M-Q16748
Subject: RE: [SIPForum-discussion] Early Media

Siva,

I'm not 100% sure but my understanding is that the early media WILL
contain
the same SDP descriptor as the 200 OK. There is a 'early-session' header
(look at RFC 3959 and 3960 for some guidance) that is used in an
Application
Server model for early media. This allows for different SDP descriptors
during session establishment.

>From my experience with PSTN-SIP Gateways (Gateway model) the
descriptor
will be the same.

Rob.

-----Original Message-----
From: Siva M-Q16748 [mailto:sivam at motorola.com]
Sent: 19 April 2007 06:49
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Early Media



Hi

In case of Early Media for announcements

Can 183 and 200OK have different SDP info 

Thanks
Siva M 

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit
http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit
http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org



________________________________

Check out what you're missing if you're not on Yahoo! Messenger
<http://us.rd.yahoo.com/mail/in/ymessenger/*http://in.messenger.yahoo.co
m/>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20070420/1d16c2c8/attachment-0002.html>


More information about the discussion mailing list