[prev in list] [next in list] [prev in thread] [next in thread]
List: sip
Subject: Re: [SIP] Operlap dialing within a SIP network
From: Gonzalo Camarillo <Gonzalo.Camarillo () lmf ! ericsson ! se>
Date: 1988-01-01 17:41:38
[Download RAW message or body]
Hello,
Mark Watson wrote:
>
> Gonzalo,
>
> I thought at the beginning of this thread Keith Robinson identified a
> number of fundamental flaws with the overlap mechanism in the draft.
> If I understood rightly, these were:
>
> 1) UAS behaviour on receiving multiple INVITES for new Call Legs of
> the same Call, but with different FROM and TO fields is undefined in
> the RFC
>
It is not defined because it does not need to be defined. Different
implementations will do different things. The RFC does not and MUST NOT
cover those situations.
For example, if I have multiple call legs in a gaming session, should
the RFC define what to do? In a conferencing environment the correct
behavior might be just to mix the media.
Anyway, a gateway will know what to do with multiple call legs that
carry more digits in the to field. If the entity receiving the INVITEs
is a UA it will not represent a problem either. The UA will process the
first INVITE and answer 484 or 404. Then, it will receive the 2nd and
try to process it. If there are nor enought digits, it will respond
again 484 or 404. If there are enough digits, the call will be
established. Thus, I do not see any problem here.
> 2) The UAC must use source routing to ensure that all these INVITES
> make it to the same UAS
What is the problem here? This is done in order to address the problem
of proxies performing load balancing. Some folks have pointed out that
maybe the betwork wants to route the second INVITE in a different way...
why the network would like to do that? The policy that is applicable to
the fist INVITE (that contained a prefix of the number) should be the
same that applies to the subsequent ones.
I do not think that the network wants that all the calls to numbers
begining by +1234 traverse proxy A, but if the prefix is +12345 should
traverse proxy B.
I do not see any real situation where the source routing performed here
might cause a problem.
> 3) 183 is used to transport the CONTACT of the UAS to UAC, but 183 may
> also cause a backwards ACM to be generated, cutting off further
> digits.
I said already that this will be clarified in the draft. However, this
has to do with the early media issue also.
>
> I may have mis-understood some of the points slightly, and there may
> be more.
>
> Overlap is a feature of the legacy PSTN - I don't think we need to
> kill ourselves making SIP support overlap in some kind of native way.
> Rather, a simple mechanism which allows consenting UAs to negotiate
> the direct exchange of overlap digits over a single Call Leg would be
> much better. It's not the same as SAMs because we can negotiate this
> mechanism to be used only once the UAS has been found. Until this
> point, calls without enough digits are killed right away with 484s.
>
> The price we pay for this is that intermediate proxies may not have
> access to the full Called Party Number - but a proxy that needs this,
> that wants to offer service on overlap calls, can always sniff the
> overlap digits as they go past.
Let me get this straight. Are you are proposing to change the logic in
all the already existing proxies because you want to provide services
when you use INFO for carrying SAMs? This is just impossible.
I still prefer a mechanism that do not require changes in the existing
proxies (multiple call-legs).
Best regards,
Gonzalo
>
> Regards,
>
> Mark Watson
> Nortel Networks
>
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: 07 February 2001 02:52
> > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > Cc: Christer Holmberg; sip@lists.bell-labs.com
> > Subject: Re: [SIP] Operlap dialing within a SIP network
> >
> >
> > Hi Tom,
> >
> > Still I want to have full state in every SIP message. If the call is
>
> > addresed to the phone number 1234, I want to have a to field that
> says
> > 1234. I do not care if there is a leg routed thru the PSTN and
> another
> > thru SIP.
> >
> > Carrying full state is one of the beauties of SIP. If we begin using
>
> > INFO for this, it would be the same as using SAMs. Differen names,
> the
> > same thing... I do not want to re-create ISUP using SIP. I
> > believe that
> > if the session has a destination, it should be present in the
> > to field.
> >
> > Again, if a proxy is providing services for this particular call, it
>
> > will want to see the called party number in order to trigger
> > the proper
> > service. This is a very good reason for updating the to field
> > every time
> > we have more digits.
> >
> > I like to use SIP between two gateways because it is possible
> > to provide
> > SIP services for a PSTN to PSTN call. If all we want to do is
> > finding a
> > egrees gateway, we would probably want to use other protocols (TRIP
> &
> > SIGTRAN for instance).
> >
> > Regards,
> >
> > Gonzalo
> >
> > Tom-PT Taylor wrote:
> > >
> > > Sorry, we're talking past each other. The premise of my
> > statements is
> > > that an INVITE has reached a UAS which has accepted it. It
> follows
> > > that the UAS did not send back a 484, but rather an interim
> > response.
> > > IF more digits come along, the INFO method is there to carry them.
>
> > > They do not affect the SIP call state; they are used beyond the
> UAS,
> > > either in a PSTN call or in another SIP call as the case may be.
> > >
> > > > -----Original Message-----
> > > > From: Gonzalo Camarillo
> [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > > > Sent: Tuesday, February 06, 2001 9:10 PM
> > > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > > Cc: Christer Holmberg; sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] Operlap dialing within a SIP network
> > > >
> > > >
> > > > Hello Tom,
> > > >
> > > > Tom-PT Taylor wrote:
> > > > >
> > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call
> > > signalling
> > > > > has reached an egress gateway, SIP has done its job --
> > additional
> > > > > digits will not change call state. It is therefore
> > > > reasonable to use
> > > > > INFO to carry the additional digits. If we are talking
> > > > ISUP-SIP, once
> > > > > the destination UAS or a UAS in a B2BUA has been
> > reached, the same
> > >
> > > > > consideration applies.
> > > > >
> > > >
> > > > I do not agree with these two statements:
> > > >
> > > > The 1st INVITE (with just some digits) arrives to a
> > vanilla SIP UA.
> > > I
> > > > will return a Not Found or a 484 Address incomplete. The
> > > > subsequent INFO
> > > > carrying more digits will be discarded. Thus, the PSTN to SIP
> > > gateway
> > > > will have to re issue a new INVITE with all the digits.
> > > > Therefore, it is
> > > > better to begin directly using er-INVITEs rather than INFO.
> > > >
> > > > Besides, I do not think that SIP is just a transport protocol
> that
> > > > carries ISUP messages between two gateways. For that, we have
> > > already
> > > > SIGTRAN. SIP might be used to provide services, even when the
> > > > call is a
> > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete
> > > > state. And a
> > > > SIP message with an incomplete to field does not carry complete
> > > state.
> > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call
>
> > > based
> > > > on the to field (called party number). That proxy would
> > like to see
> > > an
> > > > updated to field, not just a to field that contains just some
> > > digits.
> > > >
> > > > Best regards,
> > > >
> > > > Gonzalo
> > > >
> > > >
> > > > > > -----Original Message-----
> > > > > > From: Christer Holmberg
> > > [mailto:christer.holmberg@lmf.ericsson.se]
> > > > > > Sent: Tuesday, February 06, 2001 1:15 AM
> > > > > > To: Gonzalo Camarillo
> > > > > > Cc: sip@lists.bell-labs.com
> > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Gonzalo,
> > > > > >
> > > > > > I didn't say I am going to use INFO, but that is what has
> > > > > > been proposed
> > > > > > earlier in this thread, so I assumed INFO would be used. The
>
> > > > > > reason for
> > > > > > the discussion from the beginning was that the overlap
> > > signalling,
> > > > > > according to the SIP-ISUP mapping draft, may not work
> > > > very well, and
> > > > > a
> > > > > > solution using 18x responses and INFO messages, instead of
> 484
> > > and
> > > > > > re-INVITEs, was proposed.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Christer Holmberg
> > > > > > Ericsson Finland
> > > > > >
> > > > > >
> > > > > >
> > > > > > Gonzalo Camarillo wrote:
> > > > > > >
> > > > > > > Hello Christer,
> > > > > > >
> > > > > > > Why are you using INFO for sending extra digits?
> > > > > > >
> > > > > > > Please, check the SIP-ISUP mapping draft, overlap
> > > > > > signalling section.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Gonzalo
> > > > > > >
> > > > > > > Christer Holmberg wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > The discussion about overlap dialing has been pretty
> much
> > > > > > about calls
> > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN.
> > > > > > > >
> > > > > > > > Consider the following scenario.
> > > > > > > >
> > > > > > > > PSTN PHONE GW SIP SERVER
> > SIP UAS
> > > > > > > >
> > -----------------------------------------------------------
> > > > > > > >
> > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> |
> > > > > > > > | <- 18x ------ |
> > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> |
> > > > > > > > | <- 200 (INFO) |
> > > > > > > > | <- 18x ------ |
> > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> |
> > > > > > > > | <- 200 (INFO) | -- INVITE
> > > > > > > > -->
> > > > > > > > | <- 200 (INVITE)| <- 200
> ------
> > > > > > > >
> > > > > > > > In this case, the SIP server (note that I am not using
> > > > > > the word 'proxy')
> > > > > > > > must collect digits, sent from the PSTN side using
> > > > > > overlap dialing, to
> > > > > > > > be able to find the SIP UAS, and INFO is used to provide
>
> > > > > > the digits
> > > > > > > > after the INVITE has been sent.
> > > > > > > >
> > > > > > > > My question is, should a SIP server (proxy, if you like)
>
> > > > > > be allowed to
> > > > > > > > behave like this, or MUST it send 486s, and receive new
> > > > > > INVITEs, until
> > > > > > > > it is able to find the UAS?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Christer Holmberg
> > > > > > > > Ericsson Finland
> > > > > > >
> > > > > > > --
> > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71
> > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35
> > > > > > > Telecom R&D Fax : +358 9 299 30 52
> > > > > > > FIN-02420 Jorvas Email :
> > > > Gonzalo.Camarillo@ericsson.com
> > > > > > > Finland http://www.hut.fi/~gonzalo
> > > > > >
> > > >
> > > > --
> > > > Gonzalo Camarillo Phone : +358 9 299 33 71
> > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35
> > > > Telecom R&D Fax : +358 9 299 30 52
> > > > FIN-02420 Jorvas Email :
> Gonzalo.Camarillo@ericsson.com
> > > > Finland http://www.hut.fi/~gonzalo
> > > >
> >
> > --
> > Gonzalo Camarillo Phone : +358 9 299 33 71
> > Oy L M Ericsson Ab Mobile: +358 40 702 35 35
> > Telecom R&D Fax : +358 9 299 30 52
> > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com
> > Finland http://www.hut.fi/~gonzalo
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> >
--
Gonzalo Camarillo Phone : +358 9 299 33 71
Oy L M Ericsson Ab Mobile: +358 40 702 35 35
Telecom R&D Fax : +358 9 299 30 52
FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com
Finland http://www.hut.fi/~gonzalo
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic