Subject: RE: [Sip] Early media query

From: "Xia, Zhi Feng \(Bruce\)" <[email-masked]>
Date: Tue, 3 Oct 2006 11:49:23 +0800

I prefer method 4. This is also the requirement of some big service provider's application(e.g. China Telecom CRBT application). Note the media attibute in 183 should be set to "sendonly".
 
Regards,
Zhifeng

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
Sent: 2006年10月2日 20:57
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Early media query

Hi,
 
You can use Method 2, assuming the 18x and 200 have different To tag values. Otherwise you can use Method 3 or 4 (message 9 in Method 3, and message 7 in Method 4, seem to go in the wrong direction, though).
 
Regards,
 
Christer

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: 2. lokakuuta 2006 12:57
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] Early media query

Hi, 

I want to made an application where we can use early media for playing initial in-band announcements, and then finally connecting the caller to actual callee (eg prepaid card application). 

I want to know which is the correct way to support this as per SIP RFC. 

Method 1: 

                 Caller                        Callee 
                   |                             | 
                   |                             | 
                   |(1) INVITE with offer        | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(2) 183 with answer 1        | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(3) 200 OK with SDP          | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(4) ACK                      | 
                   |---------------------------->| 
                   |                             | 

(2) contains SDP of announcement server 
(3) contains SDP of callee 

Method 2: 

                                        Caller                        Callee 
                   |                             | 
                   |                             | 
                   |(1) INVITE with offer        | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(2) 183 with answer 1        | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(3) PRACK                    | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(4) 200 PRACK                | 
                   |<----------------------------| 
                   |                             | 
                   |                                    | 
                   |(5) 200 INVITE with sdp      | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(6) ACK                      | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |                             | 
                   |                             | 

(2) contains SDP of announcement server 
(5) contains SDP of callee 

Method 3: 

        Caller                        Callee 
                   |                             | 
                   |                             | 
                   |(1) INVITE with offer        | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(2) 183 with answer 1        | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(3) PRACK                    | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(4) 200 PRACK                | 
                   |<----------------------------| 
                   |(5) 200 OK                   | 
                   |<----------------------------| 
                   |                             | 
                   |(6) ACK                      | 
                   |---------------------------->| 
                   |                             | 
                   |(7)Re-INVITE with SDP        | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(8) 200 OK with SDP          | 
                   |---------------------------->| 
                   |                             | 
                   |(9) ACK                      | 
                   |---------------------------->| 

(2) contains SDP of announcement server 
(5) contains no SDP 
(7) contains SDP of callee 
(8) contains answer of caller for callee offer 

Her, UDATE can also be used instead of Re-invites. 

Method 4: 

                                            Caller                        Callee 
                   |                             | 
                   |                             | 
                   |(1) INVITE with offer        | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(2) 183 with answer 1        | 
                   |<----------------------------| 
                   |                             | 
                   |                             | 
                   |(3) PRACK                    | 
                   |---------------------------->| 
                   |                             | 
                   |                             | 
                   |(4) 200 PRACK                | 
                   |<----------------------------| 
                   |(5) UPDATE (callee offer)    | 
                   |<----------------------------| 
                   |                             | 
                   |(6) 200 UPDATE (answer)      | 
                   |---------------------------->| 
                   |                             | 
                   |(7) 200 INVITE               | 
                   |---------------------------->| 
                   |                             | 
                   |(8) ACK                      | 
                   |---------------------------->| 

In this case, when callee answers, UPDATE is sent to caller to negoitate audio with caller, and then 200 OK is sent for the initial INVITE. 

Regards, 
Udit

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Manpreet Singh <[email-masked]>
Date: Tue, 3 Oct 2006 07:59:30 -0400

Yes agreed but arent we assuming that the application server doing the
prepaid application is really a B2BUA so the origin field is always the
B2BUA but the stream is changed based on where the media is played from or
bridged to? Also my bad with the origin field, got mixed with the version
field.

M

-----Original Message-----
From: Darshan Bildikar [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 1:28 AM
To: 'Manpreet Singh'; 'Retesh Chadha'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sip-implementors] Early media query

Quoting RFC 3264 Section 8

   Nearly all aspects of the session can be modified.  New streams can
   be added, existing streams can be deleted, and parameters of existing
   streams can change.  When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP

Why I am saying there is a problem with this is because

In the first answer you are probably giving the caller the announcement
server SDP (i.e. something like o=mediaserver) and then later updating it
with the callee SDP (i.e. something like o=calleeside). If you don't have a
B2BUA in between that actually changes the origin line of SDP (i.e. to
something like o=APPSERVER) then the flows would actually be invalid because
of this restriction. 

The flows that are described are generally used. I am not saying that they
must not be used. What I am saying is that the RFC 3264 places a restriction
on them in terms of origin line. 

However, I don't think this restriction is valid, coz if a change the IP is
allowed why not a change in origin line? 

This is what I am trying to get clarified. 

________________________________________
From: Manpreet Singh [mailto:[email-masked]]
Sent: Tuesday, October 03, 2006 9:56 AM
To: Darshan Bildikar; 'Retesh Chadha'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [Sip-implementors] Early media query
Importance: High

I would say 3 makes total sense as the Re-invite is happening after a dialog
is complete so not sure why the spec wont allow it. So it would be more or
less a mid call change ( in confirmed state ) happening from a callee side
which would be the application server trying to bridge the call to the
called party skipping the announcement server. 3 should work fine and the
origin field has to be changed because now the call needs to be bridged to
the called party which is a whole new endpoint supporting different codecs
with different connection identifiers etc.
I'd say why not just send the 200OK with the answer to the initial offer in
the Invite and then play the annoucement and then bridge using a re-invite.
Unless you are trying to save the time charged till the annoucement is
played, which a lot of prepaid apps try to do, then this thing gets
complicated. I guess in that case, the application server can send the
answer in rel-183 and then the moment the call needs to be bridged, send a
200Ok and a re-invite, which is exactly what is shown in (3). 
M
-----Original Message-----
From: Darshan Bildikar [mailto:[email-masked]]
Sent: Monday, October 02, 2006 11:56 PM
To: 'Retesh Chadha'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Sip] RE: [Sip-implementors] Early media query I don't think that
even Method 3 and 4 are OK because they will involve a change in the origin
line parameter of the SDP and that is not allowed as per the RFC. 
BTW, what was the rationale behind not allowing the origin line to change? 
It makes implementing apps like prepaid and CRBT very difficult. Could
someone please throw some light on this? 
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Retesh Chadha

Sent: Monday, October 02, 2006 5:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip-implementors] Early media query Hi Udit Of all the methods
you have specified, Method 1 and 2 are wrong as per the RFC which states
that the sdp of all the provisional and 2xx response of INVITE should be
same if they are present.
Both Method 3 and 4 look fine, with method 4 being better because in that
case 200 ok for INVITE is only sent when the final negotiation (call media)
is done.
Hope this helps. 
--
With Regards
Retesh Chadha

---

From: "Xia, Zhi Feng \(Bruce\)" <[email-masked]>
Date: Tue, 10 Oct 2006 09:43:06 +0800

Quoting response from Retesh Chadha:
>>Of all the methods you have specified, Method 1 and 2 are wrong as per
>>the RFC which states that the sdp of all the provisional and 2xx
>>response of INVITE should be same if they are present.

Retesh I think you are quoting RFC3261 section 13.2.1? Please confirm. I could not find the exact statement in the RFC.
      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

Because method 3 and 4 requires an origin field change which conflicts with RFC3264. See Darshan's comments.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: 2006?10?9? 20:47
To: Xia, Zhi Feng (Bruce)
Cc: Darshan Bildikar; [email-masked]; [email-masked]; Retesh Chadha
Subject: Re: [Sip] Re: [Sip-implementors] Early media query

The Replaces approach is a possibility. But please explain why you think 
all the possibilities are invalid.

	Paul

Xia, Zhi Feng (Bruce) wrote:
> Given the restrictions in RFC, all four methods seem invalid.
> 
> Before we can change the restrictions in the RFC,  it looks to me using "replaces" is a better approach...
> 
> How about this flow:
> 
>>        Caller                                     Callee
>>                   |                                            |
>>                   |                                            |
>>                   |(1) INVITE with offer        |
>>                   |---------------------------->    |
>>                   |                                           |
>>                   |                                           |
>>                   |(2) 183 with answer 1    |
>>                   |<-------------------------------|
>>                   |                                           |
>>                   |                                           |
>>                   |(3) PRACK                       |
>>                   |---------------------------->   |
>>                   |                                           |
>>                   |                                           |
>>                   |(4) 200 PRACK               |
>>                   |<------------------------------|
>>                   |(5) 200 OK                      |
>>                   |<----------------------------  |
>>                   |                                         |
>>                   |(6) ACK                           |
>>                   |(7)Re-INVITE(replaces with new call id)
>>                   |   NOTIFY                       |
>                      |----------------------------->
>                      |BYE(the original call id)
>                      |----------------------------->
>>                   |                                        |
>>                   |(8) 200 OK with SDP   |
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 2006?10?5? 22:52
> To: Darshan Bildikar
> Cc: [email-masked]; [email-masked]; 'Retesh Chadha'
> Subject: [Sip] Re: [Sip-implementors] Early media query
> 
> 
> 
> 
> Darshan Bildikar wrote:
>> I don't think that even Method 3 and 4 are OK because they will involve a
>> change in the origin line parameter of the SDP and that is not allowed as
>> per the RFC. 
> 
> Which RFC?
> 
> I suport Crister's response.
> 
> 	Paul
> 
>> Subject: Re: [Sip-implementors] Early media query
>>
>> Hi Udit
>> Of all the methods you have specified, Method 1 and 2 are wrong as per
>> the RFC which states that the sdp of all the provisional and 2xx
>> response of INVITE should be same if they are present.
>>
>> Both Method 3 and 4 look fine, with method 4 being better because in
>> that case 200 ok for INVITE is only sent when the final negotiation
>> (call media) is done.
>>
>> Hope this helps.
>