santoshkumar pati wrote:
> Hi All,
> Can u plz answer me what is the Difference between,
> Early Media,Late Media and Early Dialog and Late Dialog.
Early media means media transmitted before the 200 OK. Late media is the
converse of that.
An early dialog is a dialog that has been established before the 200 OK.
A late dialog is the converse of that. The dialog is established when
the UAC first receives a response with a To-tag.
These are independent: you can have early media without an early dialog,
and you can have an early dialog without early media.
Paul
> Regards
> Santosh
>
>
>
> On 1/9/08, *Paul Kyzivat* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> To answer your last question - it can certainly make sense in some
> cases. An example is a fault tolerant UA with multiple instances.
>
> In any case it is not the business of the registrar to decide if it
> makes sense - the UA gets to decide what sort of contact it wants to
> use. The registrar is expected to route to the registered contact using
> the standard rules, which includes DNS lookups if the contact contains a
> domain name.
>
> I suppose you could construct your registrar to reject REGISTER requests
> when the contact contains a domain name. But you would then cease to be
> a fully compliant registrar. That may be fine in your case. But the DNS
> mapping only costs if the contact contains a domain name. If your UAs
> don't use domain names you won't incur the cost. Having support for the
> domain name will make your implementation more complete.
>
> Paul
>
> Raj Jain wrote:
> > On Jan 9, 2008 9:31 AM, Paul Kyzivat <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >> If its fully distributed with no central point of control, then
> >> presumably the individual line cards (UAs) become
> available/unavailable
> >> independently. That seems inconsistent with the desire to have a
> single
> >> registration enable routing to them all. It would seem that each
> would
> >> be needing to register independently.
> >
> > While correct in theory, the issue with that is explosion of REGISTER
> > messages. With 'n' AoRs where each has 'm' Contacts, you would have
> > n*m REGISTER messages at the start up and then at every refresh
> cycle.
> >
> > It's not that SIP doesn't support what we're trying to do, but we're
> > basically after optimization. Let's review the key question again:
> >
> > Does it make sense to use FQDNs in Contact URIs? Is the Contact
> > fundamentally supposed to identify a device? There may a couple of
> > corner cases (like the one I stated earlier) where it might be
> okay to
> > use FQDNs in Contact. However, what happens when someone sends an
> FQDN
> > in the Contact URI in a 200 OK and then ACK goes to wherever the DNS
> > tells you to send it to (assume non-record-routing proxies in the
> > middle)?
> >
> > --
> > Raj
> >
> >
> >> Raj Jain wrote:
> >>>> Then I am very confused. Why are hundreds of contacts bound to
> a single
> >>>> AOR? When a caller addresses a call to the AOR, can it really be
> >>>> answered by any of hundreds of devices? The only situation I
> am aware of
> >>>> that fits that description is a call center. But it doesn't
> sound like
> >>>> that is what you have.
> >>> Yes it can be answered by any of hundreds of devices. Its not
> exactly
> >>> a call center but close enough for the purpose of this discussion.
> >>> I've explained about the system in another post, but here it is
> again:
> >>>
> >>> It's a key telephone system. We live and breathe Shared Line
> Appearances.
> >>> The system is fully-distributed with no central point of control,
> >>> whatsoever. The system is comprised of tiny trunk cards (due to
> legacy
> >>> reasons) that have now been converted to SIP UAs. The system is
> highly
> >>> scalable and as result there can be hundreds of these SIP UA
> cards installed
> >>> in a single system. These trunk cards are "created equal" -
> i.e. anyone of
> >>> them can take you to the same extension (AoR). An AoR is
> registered with the
> >>> Registrar/Proxy when a user logs-in. To hide the multiplicity
> of these SIP
> >>> UA cards from the external world we've fronted them with a SIP
> Proxy Server.
> >>> The proxy server load balances traffic to these line cards in
> some fashion.
> >> If its fully distributed with no central point of control, then
> >> presumably the individual line cards (UAs) become
> available/unavailable
> >> independently. That seems inconsistent with the desire to have a
> single
> >> registration enable routing to them all. It would seem that each
> would
> >> be needing to register independently.
> >>
> >> So I am still groping to understand the constraints of the problem.
> >>
> >> Paul
> >>
> >>
> >>> --
> >>> Raj
> >>>
> >>>
> >>>> Paul
> >>>>
> >>>>
> >>>>> The fundamental issue is how to tell the Location Service
> that a particular
> >>>>> AoR can be reached by hundreds of IP addresses. We said it is
> impractical to
> >>>>> carry all the IP addresses in a REGISTER so let's put them in
> the Location
> >>>>> Service using some out-of-band mechanism, and then use
> REGISTER to turn the
> >>>>> bindings on or off. Using an FQDN (which may not exist in
> DNS) in the
> >>>>> Contact: is a subtly different point, but I think it seems
> okay to do so.
> >>>>>
> >>>>> --
> >>>>> Raj
> >>>>>
> >>>>>
> >>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote:
> >>>>>>> From: "Raj Jain" <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
> >>>>>>>
> >>>>>>> On Jan 7, 2008 1:54 PM, <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> >>>>>>> > I'm not sure whether it makes to sense to use
> >>>>>> domain names in a
> >>>>>>> > Contact URI. The SIP ABNF allows it. Any thoughts
> >>>>>> or suggestions on
> >>>>>>> > this?
> >>>>>>> >
> >>>>>>> > It is legal to do so, and it is mandatory that a
> >>>>>> registrar/proxy
> >>>>>>> > support it correctly, as the registrar does not
> >>>>>> control the contact
> >>>>>>> > addresses that UAs will present to it.
> >>>>>>>
> >>>>>>> Define "support it correctly". If my Registrar uses its
> >>>>>> own database
> >>>>>>> to resolve a domain name in a Contact URI instead of
> >>>>>> querying DNS,
> >>>>>>> then am I violating any normative statements made in any
> RFC?
> >>>>>>>
> >>>>>>> I suppose it depends on what is in the database. If that
> >>>>>> matches what
> >>>>>>> DNS returns, or it is correct in the context for domain
> >>>>>> names that the
> >>>>>>> Registrar has some knowledge about, that would seem OK.
> >>>>>>>
> >>>>>>> > I don't know what the constraints in your design are,
> >>>>>> but have you
> >>>>>>> > considered using a URI-parameter? If your redirection
> >>>>>> service carries
> >>>>>>> > the URI-parameter form the AOR to the registered
> >>>>>> contact, then you can
> >>>>>>> > have an unlimited number of different SIP URIs that
> >>>>>> map through one
> >>>>>>> > registration to distinct contact URIs.
> >>>>>>>
> >>>>>>> Let me try to understand this. We didn't really have a
> >>>>>> redirection
> >>>>>>> service in mind. We were thinking that a Registrar and a
> >>>>>> Proxy will be
> >>>>>>> sufficient. Our goal is to bind hundreds of Contact URIs
> >>>>>> to one AoR.
> >>>>>>> We're saying that we can't carry all those Contact URIs
> >>>>>> in-line in a
> >>>>>>> REGISTER message so lets carry them "indirectly" and use
> an OOB
> >>>>>>> mechanism. I'm not sure how a Redirection Service, URI
> >>>>>> parameter helps
> >>>>>>> this situation.
> >>>>>>>
> >>>>>>> You say "Our goal is to bind hundreds of Contact URIs to
> one AoR."
> >>>>>>> without specifying what those contact URIs might be. Would
> it be
> >>>>>>> possible to use one base URI but to create many different
> >>>>>> derived URIs
> >>>>>>> by adding a URI-parameter?
> >>>>>>>
> >>>>>>> In any case, if you want useful advice, you should describe
> more of
> >>>>>>> the problem -- it is likely that determining a "good" solution
> >>>>>>> requires understanding why you think you need to register
> >>>>>> hundreds of
> >>>>>>> contacts for an AOR. Otherwise, all we can say is "What
> you have
> >>>>>>> suggested doesn't seem like it is going to work well."
> >>>>>>>
> >>>>>>> Dale
> >>>>>>> _______________________________________________
> >>>>>>> Sip-implementors mailing list
> >>>>>>> [email protected]
> <mailto:[email protected]>
> >>>>>>>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >>>>>>>
> >>>
> >>>
> >
> >
> >
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
