On 1/7/2011 9:21 PM, SIP Satan wrote:
> Cant we play multiple announcements by giving different SDP's in
> multiple 1xx responses provided
> each 1xx carries a different To-tag. In a way simulating forking
> environment.
Yeah, should be fine. To the other end its indistinguishable from "real"
forking.
That of course assumes that the UAC is capable of rendering media from
different early dialogs.
Thanks,
Paul
> Regards
> -Satan
>
> On Fri, Jan 7, 2011 at 8:42 PM, Paul Kyzivat <pkyzi...@cisco.com
> <mailto:pkyzi...@cisco.com>> wrote:
>
> inline
>
> On 1/7/2011 12:10 AM, Parthasarathi R (partr) wrote:
> > Hi,
> >
> > Please read inline
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>
> > [mailto:sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>] On Behalf Of
> > Nataraju A.B
> > Sent: Thursday, January 06, 2011 10:40 PM
> > To: Harlin Dyvia Helina Sathianathan
> > Cc: sip-implementors@lists.cs.columbia.edu
> <mailto:sip-implementors@lists.cs.columbia.edu>
> > Subject: Re: [Sip-implementors] Multiple early media sessions
> within a
> > samedialog
> >
> > After the first 1xx, it is not allowed to send UPDATE with a
> different
> > SDP for announcement-2.
>
> That is only true when PRACK is not used.
>
> Once the answer has been sent in a *reliable* response, then another O/A
> exchange can occur within the same dialog.
>
> > I think offer-answer model discussed some set of
> > cross over scenarios in detail. If I am not wrong this is the
> scenario
> > you are looking for ?
> >
> > INV -->
> > <-- 1xx(SDP)
> > --> PRACK
> > <-- 200-PRACK
> >
> > <-- UPDATE(Callee)
> > 200-UPDATE -->
> >
> > <-- UPDATE(Callee)
> > 200-UPDATE -->
> >
> > <-- 200-INVITE
> > ACK -->
>
> Yes, I presume that is what the question is about.
> That should be fine.
>
> Of course it won't work if the caller hasn't indicated support for
> 100rel and you want to send these announcements.
>
> The alternative is to treat the call as being forked serially to each
> announcement server and then to the final recipient. Each then
> establishes its own early dialog and plays its message. In that case it
> is up to the UAC to deal with and hopefully play the media from each
> early dialog. While that is a challenge if they occur in parallel, it
> should not be such a challenge if they occur serially. There is however
> no indication that these early dialogs are terminating before the next
> one starts. (But see the draft on 199.)
>
> Thanks,
> Paul
>
> > It was intentionally restricted to allow only one SDP negotiation
> during
> > session setup. Once the call is setup, you can have as many
> > re-negotiations as possible. This makes offer-answer handling UA's
> > simpler...
> > <Partha> I really don't know whether any such restriction exists
> in the
> > offer/answer draft. If so, it has to be revisited as multiple
> > announcement is common scenario in the network.</Partha>
> >
> > I suggest some more detailed study on offer-answer model draft is
> > required.
> > You are suggested to go through earlier discussion on
> offer-answer draft
> > as well.
> >
> > Hope this helps....
> >
> > On Wed, Jan 5, 2011 at 10:17 AM, Harlin Dyvia Helina Sathianathan<
> > harlin.sathianat...@aricent.com
> <mailto:harlin.sathianat...@aricent.com>> wrote:
> >
> >> Hi Nataraju,
> >>
> >>
> >>
> >> Thanks for your inputs.
> >>
> >> Sending different SDPs in multiple 1xx messages might be
> violating the
> >
> >> offer-answer model,
> >>
> >> but if the first announcement is through reliable-1xx response
> and the
> >
> >> subsequent announcement is with UPDATE, then I guess it should be
> >> technically right.
> > <Partha> This may break few callflow wherein 18x is expected to
> play the
> > announcement or change the announcement. UPDATE updates media
> part (SDP)
> > but not indicates which types of announcement. Multiple 18x may
> needed
> > but it depends upon the device which you interop</partha>
> >>
> >> Correct me if I am wrong.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Harlin
> >>
> >>
> >> ------------------------------
> >>
> >> *From:* Nataraju A.B [mailto:nataraju....@gmail.com
> <mailto:nataraju....@gmail.com>]
> >> *Sent:* Tuesday, January 04, 2011 6:36 PM
> >> *To:* Vivek Talwar
> >> *Cc:* Harlin Dyvia Helina Sathianathan; $...@r\/|>r!`/@; Worley, Dale
> R
> >> (Dale); sip-implementors@lists.cs.columbia.edu
> <mailto:sip-implementors@lists.cs.columbia.edu>
> >>
> >> *Subject:* Re: [Sip-implementors] Multiple early media sessions
> within
> >
> >> a same dialog
> >>
> >>
> >>
> >> Hi All,
> >>
> >>
> >>
> >> with in the same session, playing announcements is not allowed.
> There
> >> could be only on dialog established between UAC and
> UAS1(to_tag1). But
> >
> >> there could be multiple dialogs established @ UAC due to UAS1, UAS2,
> >> .... but not by the same UAS. Sending diferent SDPs in multiple 1xx
> >> messages would violate offer-answer model. if multiple dialogs were
> >> created in UAC / Proxy, care must be taken while passing the
> responses
> >
> >> back to User_Application/UAC
> >>
> >>
> >>
> >> you can refer *
> >>
> http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13* for
> >> more details.....
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Nataraju A.B.
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Jan 4, 2011 at 11:48 AM, Vivek Talwar
> >> <vivek.tal...@aricent.com <mailto:vivek.tal...@aricent.com>>
> >> wrote:
> >>
> >> Hi Harlin,
> >> I think you want to play two sequential early media
> announcements
> >
> >> back to back. This can be achieved with same tag but the server
> >> involved in SIP signaling for initiating early dialog have to take
> > care of this.
> >>
> >> Thanks and Regards,
> >> Vivek Talwar
> >> ________________________________________
> >> From: sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu> [
> >> sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>] On Behalf
> Of Harlin
> >> Dyvia Helina Sathianathan
> >> Sent: Tuesday, January 04, 2011 11:34 AM
> >> To: $...@r\/|>r!`/@; Worley, Dale R (Dale)
> >> Cc: sip-implementors@lists.cs.columbia.edu
> <mailto:sip-implementors@lists.cs.columbia.edu>
> >> Subject: Re: [Sip-implementors] Multiple early media sessions
> within a
> >
> >> same dialogHdOcDalPowerHogList
> >>
> >>
> >> Hi,
> >>
> >> Thanks all for your inputs.
> >>
> >> This is my query:
> >> An UAC sends INVITE to a soft switch and the soft switch needs
> to play
> >
> >> two early announcements to the UAC and then connect the call to the
> >> destined user.
> >> So, the early announcements are played using Reliable Provisional
> >> Responses with same tags.
> >> Is it possible in real time to establish two early session (with
> same
> >> tag) between UAC and the soft switch ?
> >>
> >> Regards,
> >> Harlin
> >> ________________________________
> >> From: $...@r\/|>r!`/@ [mailto:sarvpriyagu...@gmail.com
> <mailto:sarvpriyagu...@gmail.com>]
> >> Sent: Tuesday, January 04, 2011 9:16 AM
> >> To: Worley, Dale R (Dale)
> >> Cc: Harlin Dyvia Helina Sathianathan;
> >> sip-implementors@lists.cs.columbia.edu
> <mailto:sip-implementors@lists.cs.columbia.edu>
> >> Subject: Re: [Sip-implementors] Multiple early media sessions
> within a
> >
> >> same dialog
> >>
> >> Hello guys,
> >>
> >> I gues he is only referring multiple announcements within the same
> > dialog.
> >> He is not referring to multiple UACs.
> >>
> >> Harlin,
> >> Will you please explain iwhat exactly is your scenario. Is it
> >> different announcements to different UACs or multiple
> announcements to
> > one UAC?
> >>
> >> cheers!!
> >> sarvpriya
> >> On Mon, Jan 3, 2011 at 11:29 PM, Worley, Dale R (Dale)
> >> <dwor...@avaya.com
> <mailto:dwor...@avaya.com><mailto:dwor...@avaya.com
> <mailto:dwor...@avaya.com>>> wrote:
> >> ________________________________________
> >> From: sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu><mailto:
> >> sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>> [
> >> sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu><mailto:
> >> sip-implementors-boun...@lists.cs.columbia.edu
> <mailto:sip-implementors-boun...@lists.cs.columbia.edu>>] On Behalf
> Of Harlin
> >> Dyvia Helina Sathianathan [harlin.sathianat...@aricent.com
> <mailto:harlin.sathianat...@aricent.com><mailto:
> >> harlin.sathianat...@aricent.com
> <mailto:harlin.sathianat...@aricent.com>>]
> >>
> >> ________________________________
> >>
> >> No, since there can be only one session associated with a single
> > dialog.
> >> But an INVITE can create multiple early dialogs by reaching
> multiple
> >> destinations, and so the UAC must be prepared to receive several
> early
> >
> >> sessions simultaneously. Because 1xx responses are not sent
> reliably,
> >
> >> the UAC may not receive SDP for some of the early sessions. The
> only
> >> way to distinguish them is by heuristic means.
> >>
> >> Dale
> >>
> >> _______________________________________________
> >> Sip-implementors mailing list
> >> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu><mailto:
> >> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>>
> >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >>
> >>
> >>
> >> --
> >> cheers!!!!
> >> sarvpriya
> >> http://sarvpriyak.blogspot.com/
> >>
> >>
> >> ________________________________
> >> "DISCLAIMER: This message is proprietary to Aricent and is intended
> >> solely for the use of the individual to whom it is addressed. It may
> >> contain privileged or confidential information and should not be
> >> circulated or used for any purpose other than for what it is
> intended.
> >
> >> If you have received this message in error, please notify the
> >> originator immediately. If you are not the intended recipient,
> you are
> >
> >> notified that you are strictly prohibited from using, copying,
> >> altering, or disclosing the contents of this message. Aricent
> accepts
> >> no responsibility for loss or damage arising from the use of the
> >> information transmitted by this email including damage from virus."
> >> _______________________________________________
> >> Sip-implementors mailing list
> >> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >>
> >> "DISCLAIMER: This message is proprietary to Aricent and is intended
> >> solely for the use of the individual to whom it is addressed. It may
> >> contain privileged or confidential information and should not be
> >> circulated or used for any purpose other than for what it is
> intended.
> >
> >> If you have received this message in error, please notify the
> >> originator immediately. If you are not the intended recipient,
> you are
> >
> >> notified that you are strictly prohibited from using, copying,
> >> altering, or disclosing the contents of this message. Aricent
> accepts
> >> no responsibility for loss or damage arising from the use of the
> >> information transmitted by this email including damage from virus."
> >>
> >> _______________________________________________
> >> Sip-implementors mailing list
> >> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >>
> >>
> >>
> >>
> >> --
> >>
> >> ------------------------------
> >> "DISCLAIMER: This message is proprietary to Aricent and is intended
> >> solely for the use of the individual to whom it is addressed. It may
> >> contain privileged or confidential information and should not be
> >> circulated or used for any purpose other than for what it is
> intended.
> >
> >> If you have received this message in error, please notify the
> >> originator immediately. If you are not the intended recipient,
> you are
> >
> >> notified that you are strictly prohibited from using, copying,
> >> altering, or disclosing the contents of this message. Aricent
> accepts
> >> no responsibility for loss or damage arising from the use of the
> >> information transmitted by this email including damage from virus."
> >>
> >
> >
> >
> > --
> > Thanks,
> > Nataraju A.B.
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>
>
> --
> Regards
> -Satan
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
