[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

答复: Re: PRACK: Does an early-session SDP offer fullfills the rule to insert SDP in first reliable response




Hi,

[Paul] Whether there is a use case where that makes sense remains to be seen.

If AS(application server) want to play a (coloring) ring back to the caller,

or it want to play some tones to notice the caller that the call is forward, or
the call is waiting, etc, AS could insert an early-session offer in the 180.

Regards
Eric







wang.libo@xxxxxxxxxx wrote:

>  > IMO the "early-session" and the "session" must each independently comply
>  > with the o/a rules. So if you take any call flow using early-session,
>  > and transform it in either of the following ways, the transformed flow
>  > should still be valid according to the normal rules for o/a using
> "session":
>  >
>  > 1) remove all the body parts with content-disposition of "early-session"
>  > and content-type "application/sdp". Then if that results in
>  > multipart/mixed body parts containing only an application/sdp body part
>  > with c-d of session, remove the multipart, leaving just the sdp in its
>  > place. Then remove any Supported/Required references to early-session.t
>  >
>  > 2) remove all the body parts with content-disposition of "session" and
>  > content-type "application/sdp". Then if that results in multipart/mixed
>  > body parts containing only an application/sdp body part with c-d of
>  > early-session, remove the multipart, leaving just the sdp in its place.
>  > Then replace occurrences of C-D:early-session with C-D:session. Then
>  > remove any Supported/Required references to early-session.
>  >
>
> If I catch you, you mean, if early-session and session exist in the same
> signal,how to place the content-type/content-disposition.You can place
> content-type/content-disposition with just the SDP,and place
> "Content-Type: multipart/mixed" at the front.
>
> e.g:
>
> Content-Type: multipart/mixed;boundary=---boundary-boundary---
>
> ---boundary-boundary---
> Content-Type: application/SDP
> Content-Disposition: session
> v=0
> o=
> s=session SDP
> c=
>
> ---boundary-boundary---
> Content-Type: application/SDP
> Content-Disposition: early-session
> v=0
> c=
>
> ---boundary-boundary---

Yes. For instance an invite might include a session offer.
Then a reliable 180 could contain both an answer to the received offer,
and an early-session offer.

Whether there is a use case where that makes sense remains to be seen.

                Paul

>  > In theory, the above would allow the UAC to initiate both, but in
>  > practice that would make no sense.
>  >
>
> In the initial INVITE,the UAC needn't initiate the early-session.
> But if UAC want to alert the CALLED-UA (e.g UAC want to play some
> special music for CALLED-UA), UAC can initiate the early-sesion.
>
>
>
>  > If what I say is correct, then it relaxes no restrictions on anybody.
>  >
>  > I don't understand why anybody would bother with early-session. For the
>  > cases where it might be useful I think the same effect can be
>  > accomplished easier by simply establishing an early dialog with one
>  > to-tag, and a different early/final dialog with a different to-tag.
>  >
>
> Yes.
> Early-session plays the same role as the fork early dialog, but if 199
> is not implemented, and the call is forwarded, there may exist several
> fork early dialogs, which one the UAC shold choose is problem.
>
> IMO, the two methods both have advantages!
>  
>
> Regards,
> Eric
>
>  >    Paul
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

Add to Google Powered by Linux