Trying to respond to all the discussers in one response - inline.
(BTW, I'm not seeing the blue. Would prefer conventional quoting.)
Paul
Ben Gatewood wrote:
Hi Ben,
I have some queries in BLUE.
-----Original Message-----
From: Ben Gatewood [ <mailto:[EMAIL PROTECTED]>
mailto:[EMAIL PROTECTED]
Sent: Friday, October 28, 2005 5:45 PM
To: Naveen Kak (WT01 - Voice & Next Generation Networks);
[email protected]
Subject: RE: [Sip-implementors] Offer-Answer in SIP
Hey Naveen - Responses inline.
Hi all,
As per the RFC, if the "Offer" is send in INVITE, then the "Answer" can
be received in any of the provisional responses( 180,183 ..) or a 200
OK.So then theoretically, media can start flowing in even if a final
response is not received( if the Answer comes in a provisional
response).Is this behavior correct?
Not only correct but required in certain PSTN interworking scenarios.
In certain PSTN scenarios, they are required for one way audio ( ring tone
to be played
Back to the caller).
I was thinking more of announcements stating your call had been unsuccessful
but.yes.
But actually a 2 way audio can be established without a 200 OK coming in
picture?Is that right??
Yes but I'm struggling to think of any meaningful media you could send in
this direction for this scenario.
It turns out that there are some PSTN features that seem to require
this. In particular, there are some features that prompt for a PIN
before permitting the call to proceed. Two-way audio before answer is
one way to handle those in sip.
In theory, media can be sent from the answerer to the offerer as soon as
the offer is received, even if the answer has not been sent. (In fact,
even if *nothing* has yet been sent from the potential answerer to the
offerer.)
Then, in theory, two way media becomes possible as soon as the offerer
has received an answer, regardless of the state of the call.
In practice, this can be difficult to realize in many environments.
Opening pinholes in NATs and Firewalls is one issue. Another is that
before the call is fully established, forking can result in there being
multiple answerers, and it is unknown which the call will eventually be
with.
Imagine a case where the call is forked to two destinations. Both have
enabled a DND feature with PIN override. Both send back media with a
prompt for a pin, and both await a media response with a PIN in DTMF.
Moreover, what if the Answer comes in a provisional response and then
200 OK also returns an Answer. Can both the Answers differ( lets say as
per the proviosnal reponse G.711 is the chosen codec and then 200 OK
returns G.729 as the chosen codec).
No.
Does that mean if a proviosonal response contains an Answer, either the 200
OK can't send another Answer or the Answer has to be same as in the
provisonal reponse???
I should have also specified that the answer has to be in a reliable
provisional response. If such an answer is sent then I don't believe you are
required to put the answer in the final response again but if you do, it has
to be the same. I believe most implementations copy the answer in the final
response rather than omitting it.
See draft-sawada-sipping-sip-offeranswer-00.doc.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors