Subject: [SIP] proxy and RTP

From: rufin soh <[email-masked]>
Date: Thu, 21 Dec 2000 14:52:59 +0100 (CET)

For a proxy to handle UA requests and responses very
well, I think we should consider 3 issues:
   proxy must not support any codecs in RTP or SDP.
   after a 200 response, the futher state should be
nothing other than establishing communication(without
codecs, since there is no specifications yet in drafts
about the standards to commonly adopt).
   To make port changing, proxy need to first be
registered as all sip servers, so even if a UA don't
have a proxy IP, it can just forward a request to all
sip servers address.

--- [email-masked] a écrit : > Send
SIP mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	http://lists.bell-labs.com/mailman/listinfo/sip
> or, via email, send a message with subject or body
> 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of SIP digest..."
> 
> > Today's Topics:
> 
>    1. RE: 3pcc callflow question (Was:Changin local
> RTP port with
>        out a good reason) (Fairlie-Cuninghame,
> Robert)
>    2. Re: Proxies modifying SDP (Anuraj Ennai)
>    3. RE: Proxy Routing Logic (Fairlie-Cuninghame,
> Robert)
>    4. RE: Bug in 2543bis-02 re: Record-Route (Keith
> Robinson)
>    5. Re: RE: Changin local RTP port without a good
> reason (Gonzalo Camarillo)
>    6. RE: SIP Security Mailing List (Rosen, Brian)
>    7. RE: Record-Route and REGISTER (Steve Donovan)
>    8. RE: RE: Changin local RTP port without a good
> reason (Steve Donovan)
> 

> ATTACHMENT part 3.1 message/rfc822 
> De: "Fairlie-Cuninghame, Robert"
> <[email-masked]>
> À: 'Robert Sparks' <[email-masked]>,
> 	[email-masked]
> Objet: RE: [SIP] 3pcc callflow question (Was:Changin
> local RTP port with
> 	out a good reason)
> Date: Tue, 19 Dec 2000 21:59:42 -0800
> 
> > 
> > Doesn't matter. Notice that in the original
> diagram, A1
> > isn't used in the negotiation with B. If A
> automatically
> > returns held sdp when it recieves held sdp, things
> don't
> > break.
> > 
> > Out of curiosity, does anyone have a UA deployed
> that won't
> > accept an initial INVITE to held media? If so, it
> argues for
> > using the delayed media approach you suggest.
> > 
> Hi Robert,
> 
> I imagine that some UA's may not be happy with an
> initial SDP (held) with no
> vocoders, eg
> 
> v=0
> o=...
> c=IN IP4 0.0.0.0
> m=audio 10000 RTP/AVP
> 
> [Otherwise the controller would have to know/guess
> the lowest capabilities
> of UA A - which is unacceptable.]
> 
> Placing no SDP in the INVITE also has the advantage
> that the controller can
> immediately take action if it detects that the 200
> Ok from UA B (containing
> SDP B) is incompatiable with SDP A1 (rather than the
> UA A re-INVITE failing
> ... which adds more chance of strange things
> happening due to incorrect UA
> re-INVITE error handling).
> 
> Regards,
> 
> Robert.
> 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf
> Of 
> > Fairlie-Cuninghame,
> > > Robert
> > > Sent: Tuesday, December 19, 2000 12:51 AM
> > > To: [email-masked]
> > > Subject: RE: [SIP] 3pcc callflow question
> (Was:Changin 
> > local RTP port
> > > without a good reason)
> > >
> > >
> > > > An alternative flow has already been proposed
> which does not
> > > > suffer from the
> > > > timeout problem, and which does not have this
> race condition:
> > > >
> > >
> > > > > >  A                Controller            B
> > > > > >  |  INV  SDP held    |                  |
> time t = 0
> > > > > >  |<------------------|                  |
> > > > > >  |                   |                  |
> > > > > >  |  200 SDP A1       |                  |
> > > > > >  |-----------------> |                  |
> > > > > >  |                   |                  |
> > > > > >  |       ACK         |                  |
> > > > > >  |<------------------|                  |
> > > > > >  |                   |                  |
> > >
> > > Sorry to go back a bit but can I forget the
> reason why it was
> > > decided not to
> > > start with:
> > >
> > > A	Controller
> > >
> > > INV no SDP
> > > <--------
> > >
> > > 200 SDP A1
> > > -------->
> > >
> > > ACK SDP held
> > > <--------
> > >
> > > This seems simpler as both A and B are behaving
> in the same 
> > manner (rather
> > > than A having to realize that it must produce
> SDP A1 when 
> > it receives an
> > > initial SDP held).
> > >
> > > Was it because of crash-restart problems ?
> > >
> > > Regards,
> > >
> > > Robert.
> > >
> > >
> > > > > >  |                   |  INV no SDP      |
> > > > > >  |                   |----------------->| 
> (1)
> > > > > >  |                   |                  |
> > > > > >  |                   |  200 SDP B       |
> > > > > >  |                   |<-----------------|
> > > > > >  |      INV SDP B    |                  |
> > > > > >  |<------------------|                  |
> > > > > >  |                   |                  |
> > > > > >  |  200 SDP A2       |                  |
> > > > > >  |-----------------> |                  |
> > > > > >  |                   |                  |
> > > > > >  |                   |  ACK  SDP A2     |
> > > > > >  |  ACK              |----------------->|
> > > > > >  |<------------------|                  |
> > > > > >  |                   |                  |
> > > > > >  |                   |       RTP        |
> > > > > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > > > > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > > > > >  |                   |                  |
> > > >
> > > >
> > > > I'd like to start with this one as the basis
> for continuing
> > > > discussion/concerns.
> > > >
> > > > -Jonathan R.
> > > >
> > > >
> > > > ---
> > > > Jonathan D. Rosenberg                       72
> Eagle Rock Ave.
> > > > Chief Scientist                            
> First Floor
> > > > dynamicsoft                                
> East Hanover, NJ 07936
> > > > [email-masked]                    
> FAX:   (973) 952-5050
> > > > http://www.cs.columbia.edu/~jdrosen        
> PHONE: (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > >
> > > >
> _______________________________________________
> > > > SIP mailing list
> > > > [email-masked]
> > > >
> http://lists.bell-labs.com/mailman/listinfo/sip
> > > >
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > 
> 
> 

> ATTACHMENT part 3.2 message/rfc822 
> Date: Wed, 20 Dec 2000 12:47:06 +0530
> De: "Anuraj Ennai" <[email-masked]>
> Affiliation: Wipro
> À: [email-masked]
> Objet: Re: [SIP] Proxies modifying SDP
> 
> Hi all,
> 
> I believe proxies should be discouraged from prying
> into SDP contents(or any message body that does
> not concern them) for scalability, security and
> privacy reasons.
> 
> The mechanism for capability negotiation etc.
> should be implemented at UA, using methods
> like OPTIONs and/or headers like supported/
> Unsupported or Re-INVITEs. It mandates passing
> 1 or 2 messages more between the UAs, but in the
> end scales up well. If the proxy needs SDP content
> negotiation, it can spawn its own call agent which
> works exactly like the UA.
> 
> In the end, it is all about KISS!!!
> 
> Thanks & regards
> Anuraj Ennai
> Wipro Technologies -India.
> 
> Subject:
>             Re: [SIP] Proxies modifying SDP
>        Date:
>             Tue, 19 Dec 2000 10:56:04 -0600
>       From:
>             David Frascone <[email-masked]>
>         To:
>             Steve Gardell <[email-masked]>
>         CC:
>             "'Baniel Uri-CUB001'"
> <[email-masked]>, [email-masked]
>  References:
>             1
> 
> 
> 
> This might be a useless response, since I can't find
> the example document that
> I'm about to refer too . . but . . .  In the
> documents I read before San Diego,
> I remember two pictures of a proxied senario.
> 
> In the first, the SIP requests were proxied, but the
> RTP was sent normally.
> 
> In the second, the SIP requests were proxied, *and*
> the RTP was proxied.  In
> this senario, didn't the SIP proxy have to modify
> the SDP to get it to work?
> 
> Please:  I know someone else read this document, or
> saw the slides I'm
> refering too . . . . Someone help refresh my poor
> tired memory :)
> 
> -Dave
> 
> On Tue, Dec 19, 2000 at 11:43:25AM -0500, Steve
> Gardell wrote:
> > If memory serves, a "fully routed" H.323
> gatekeepers routes the media
> > negotiation signalling, but does not route the
> actual RTP traffic.
> >
> > -----Original Message-----
> > From: Baniel Uri-CUB001
> [mailto:[email-masked]]
> > Sent: Monday, December 18, 2000 8:05 PM
> > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil
> Deason';
> > [email-masked]; [email-masked];
> [email-masked]
> > Subject: RE: [SIP] Proxies modifying SDP
> >
> >
> > Hmm...
> > Probably I was not clear and hence the confusion.
> > My intention was to be able to mimic the 'H323
> gate keeper mode'
> > functionality, i.e. to have the end points think
> they talk to each other (in
> > the media streaming phase) but actually the media
> goes via a gate keeper. In
> > our SIP world this should be just a MG (Media
> Gateway).
> > The control may still go via a SIP proxy server,
> that is why I think
> > changing SDP fields (specifically the IP address
> for receiving media as well
> > as the RTP ports) may easily achieve this goal
> >
> > Uri
> >
> > -----Original Message-----
> > From: Steve Donovan
> [mailto:[email-masked]]
> > Sent: Sunday, December 17, 2000 9:12 PM
> > To: Baniel Uri-CUB001; 'Neil Deason';
> [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [SIP] Proxies modifying SDP
> >
> 
> 
> 
> 
> 

> ATTACHMENT part 3.3 message/rfc822 
> De: "Fairlie-Cuninghame, Robert"
> <[email-masked]>
> À: 'Billy Biggs' <[email-masked]>,
> 	Jonathan Rosenberg <[email-masked]>
> CC: Keith Robinson <[email-masked]>,
> 	SIP List <[email-masked]>
> Objet: RE: [SIP] Proxy Routing Logic
> Date: Wed, 20 Dec 2000 00:29:28 -0800
> 
> > 
> >   If so, let's revisit the idea of copying the
> Request-URI into the
> > Route and adding an maddr.
> > 
> >   Consider an outbound proxy which adds a
> record-route.  An initial
> > request arrives for [email-masked].  The
> proxy uses 
> > an RR URI:
> > 
> >    
> sip:[email-masked];maddr=outbound.proxy.com
> > 
> >   So, when it sees new requests with this as the
> request-URI, we have
> > different behavior dependant on if there is a
> Route.  This makes me
> > worried.
> > 
> Hi Billy, 
> 
> I beleive under the new Record-Route suggestions the
> proxy would be
> recommended to add RR of
> <sip:[email-masked];blah> so that request
> is always routed to the outbound proxy (to remove
> ambiguity).
> 
> [Of course there will be always be different routing
> behaviour depending on
> whether the request has a Route or not. If a Route
> exists it would be
> followed. If the Route doesn't exist you want to
> recreate the original
> routing action (for subsequent requests). This needs
> to be accomplished by
> either storing route state local or embedding the
> imformation in the
> Record-Route.]
> 
> I don't see your maddr concerns as a problem - in
> fact it is darn useful. If
> a Contact or Record-Route has an maddr it should be
> acted upon by a UAC -
> even if the UAC has an outbound proxy configured (I
> believe).
> 
> If the outbound proxy wants to have ALL sip requests
> sent to it (not just
> the first INVITE) then it should record-route
> itself!!
> 
> If a UAC with an outbound proxy configured _wasn't_
> to act on the maddr,
> then a redirect server would be rendered useless (if
> it was configured as
> the outbound proxy).
> 
> Eg: 
> UAC send INVITE sip:[email-masked];user=phone
> SIP/2.0 to outbound
> proxy (which is redirect server).
> 
> Server returns 302 with 
> Contact:
>
<sip:[email-masked];user=phone;maddr=gateway.com>
> 
> If the UAC ignores the maddr then it would simply
> send the INVITE to the
> same outbound proxy again.
> 
> Cheers,
> 
> Robert.
> 
> 

> ATTACHMENT part 3.4 message/rfc822 
> De: "Keith Robinson" <[email-masked]>
> À: Jonathan Rosenberg <[email-masked]>
> CC: "'Neil Deason'" <[email-masked]>,
> 	Billy Biggs <[email-masked]>,
> 	Jean-Francois Mule <[email-masked]>,
> [email-masked]
> Date: Wed, 20 Dec 2000 09:17:07 +0000
> Objet: RE: [SIP] Bug in 2543bis-02 re: Record-Route
> 
> 
> 
> Requiring a proxy to add itself to each request for
> robustness in case the UA
> crashes is fine but
> it has to be MUST to be sure it stays in the path as
> it cant know when the UA is
> about to crash-reboot.
> 
> Regards,
> 
> K. Robinson
> 
> 
> 
> 

> ATTACHMENT part 3.5 message/rfc822 
> Date: Wed, 20 Dec 2000 16:11:39 +0200
> De: Gonzalo Camarillo
> <[email-masked]>
> Affiliation: Oy L M Ericsson Ab
> À: Jonathan Rosenberg <[email-masked]>
> CC: "'Pekka Pessi'" <[email-masked]>,
> [email-masked]
> Objet: Re: [SIP] RE: Changin local RTP port without
> a good reason
> 
> Hi,
> 
> Actually there is nothing new with this flow. This
> is the delayed ACK
> solution that was already proposed. Since the
> INV/200 OK will most
> likely take little time, it will work. However, when
> INV-200 OK takes
> longer we have the same problem.
> 
> In most of the situations, using the delayed ACK,
> the flow you just
> described works. However, if the SDP is not ready
> and the ACK has to be
> sent to stop the retransmission timer, we will still
> have to make up an
> SDP... we might want to work on this scenario.
> 
> Best regards,
> 
> Gonzalo
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Pekka Pessi [mailto:[email-masked]]
> > > Sent: Monday, December 18, 2000 3:30 AM
> > > To: [email-masked]
> > > Cc: Gonzalo Camarillo
> > > Subject: Re: [SIP] RE: Changin local RTP port
> without a good reason
> > >
> > >
> > > In message <[email-masked]>
> "ext Gonzalo
> > > Camarillo" <[email-masked]>
> writes:
> > > >Of course that sometimes you have to change
> your local
> > > configuration if
> > > >the remote configuration changes... but there
> has to be a good reason
> > > >(like a change of codecs).
> > >
> > >       When you issue a re-INVITE with a new
> local port number, you are
> > >         proposing a new RTP session.  The remote
> end can not
> > > distinguish
> > >         between packets in the old session and
> new session, unless it
> > >         changes its RTP port, too.
> > 
> > Much as I would like to be able to enforce this
> "don't change ports without
> > good reason", I think there are cases where
> implementations will want to do
> > this on each re-invite. As such, I think the
> mechanism in the current 3pcc
> > draft won't work either.
> > 
> > An alternative flow has already been proposed
> which does not suffer from the
> > timeout problem, and which does not have this race
> condition:
> > 
> > > >  A                Controller            B
> > > >  |  INV  SDP held    |                  | time
> t = 0
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |  200 SDP A1       |                  |
> > > >  |-----------------> |                  |
> > > >  |                   |                  |
> > > >  |       ACK         |                  |
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |                   |  INV no SDP      |
> > > >  |                   |----------------->|  (1)
> > > >  |                   |                  |
> > > >  |                   |  200 SDP B       |
> > > >  |                   |<-----------------|
> > > >  |      INV SDP B    |                  |
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |  200 SDP A2       |                  |
> > > >  |-----------------> |                  |
> > > >  |                   |                  |
> > > >  |                   |  ACK  SDP A2     |
> > > >  |  ACK              |----------------->|
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |                   |       RTP        |
> > > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > > >  |                   |                  |
> > 
> > I'd like to start with this one as the basis for
> continuing
> > discussion/concerns.
> > 
> > -Jonathan R.
> > 
> > ---
> > Jonathan D. Rosenberg                       72
> Eagle Rock Ave.
> > Chief Scientist                             First
> Floor
> > dynamicsoft                                 East
> Hanover, NJ 07936
> > [email-masked]                     FAX:  
> (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE:
> (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> -- 
> 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 : 
> [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
> 
> 

> ATTACHMENT part 3.6 message/rfc822 
> De: "Rosen, Brian" <[email-masked]>
> À: "'Johan Liseborn'" <[email-masked]>,
> 	SIP List <[email-masked]>
> Date: Wed, 20 Dec 2000 09:36:05 -0500
> Objet: [SIP] RE: SIP Security Mailing List
> 
> If you are interested in Security issues in SIP,
> please subscribe to
> the sip-security mailing list:
>   Post message: [email-masked] 
>   Subscribe:  [email-masked]  
>   Unsubscribe:  [email-masked]
>  
>   List owner:  [email-masked]  
>   URL to web page:
> http://www.egroups.com/group/sip-security 
> 
> Brian
> 
>  
> 
> 

> ATTACHMENT part 3.7 message/rfc822 
> De: "Steve Donovan" <[email-masked]>
> À: "Simon Barber" <[email-masked]>,
> 	"Jonathan Rosenberg" <[email-masked]>,
> 	"'Sean Olson'" <[email-masked]>
> CC: "'David Shrader'"
> <[email-masked]>,
> 	"SIP List" <[email-masked]>
> Objet: RE: [SIP] Record-Route and REGISTER
> Date: Wed, 20 Dec 2000 09:11:58 -0600
> 
> 
> 
> > -----Original Message-----
> > From: Simon Barber [mailto:[email-masked]]
> > Sent: Tuesday, December 19, 2000 6:13 PM
> > To: Jonathan Rosenberg; 'Sean Olson'; Steve
> Donovan
> > Cc: 'David Shrader'; SIP List
> > Subject: Re: [SIP] Record-Route and REGISTER
> >
> >
> > From: "Jonathan Rosenberg"
> <[email-masked]>
> > To: "'Sean Olson'" <[email-masked]>;
> "Steve Donovan"
> > <[email-masked]>
> > Cc: "Jonathan Rosenberg"
> <[email-masked]>; "'David Shrader'"
> > <[email-masked]>; "SIP List"
> <[email-masked]>
> > Sent: Tuesday, December 19, 2000 3:16 PM
> > Subject: RE: [SIP] Record-Route and REGISTER
> >
> >
> > > This issue is what I meant when I said:
> > >
> > > >What is the the scope of the Route? To which
> set of messages does
> > > >it apply? When can the route be purged?
> > >
> > > The obvious generalization of the current Route
> mechanism is that a UA
> > uses
> > > the Routes for all requests with the same
> To/From/Call-ID. This
> > would then
> > > effect refreshes of REGISTER, and is also how we
> handle
> > record-routing of
> > > SUBSCRIBE/NOTIFY and MESSAGE as well.
> > >
> > > What would you use RR on REGISTER for? Not
> sure... any ideas?
> >
> >
> > A firewall proxy for a large private network might
> want to keep state for
> > the registration of a UA - and also load-balance.
> This brings up
> > the further
> > question of keeping the same proxy in the loop for
> future INVITE and other
> > methods, as well as future REGISTERs.
> 
> But the can't the firewall proxy use the state that
> is already in the
> registrar to which the REGISTER is being sent?
> 
> I can see that use of record-route would make a more
> efficient method for
> routing REGISTERs to the same registrar (after the
> first is sent).  However,
> there are other methods (for instance, routing based
> on the to field).  As
> such, is it worth it to create a special way of
> handling record-routes just
> for REGISTER messages?  This seems to me to break
> the KISS principle.
> 
> more below...
> 
> > > > -----Original Message-----
> > > > From: Sean Olson
> [mailto:[email-masked]]
> > > > Sent: Tuesday, December 19, 2000 2:18 PM
> > > > To: Steve Donovan
> > > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP
> List
> > > > Subject: Re: [SIP] Record-Route and REGISTER
> > > >
> > > >
> > > > What about subsequent re-registrations? It is
> conceivable that
> > > > a stateful proxy might want to know about
> these re-registrations
> > > > (perhaps for caching purposes). Of course,
> this doesn't help
> > > > with the case where multiple UAs are
> registering for the same
> > > > user.
> 
> Again, shouldn't that stateful proxy use the
> registrar/location server for
> it's domain?  That's the only way to fix the
> multiple UA registering
> problem.
> 
> > > >
> > > > Sean
> > > >
> > > > Steve Donovan wrote:
> > > > >
> > > > > Why are we worried about record-routing
> REGISTER messages.
> > > > Record-Routing
> > > > > is used to ensure that all messages within a
> session go
> > > > through interested
> > > > > proxies.  This is obviously useful with
> INVITE and SUBSCRIBE.
> > > > >
> > > > > There is no session created by REGISTER.  As
> such, there
> > > > are no other
> > > > > messages that need to take the same route.
> > > > >
> > > > > Is the goal to ensure that subsequent
> REGISTER requests
> > > > make it to the same
> > > > > instance of a registrar within a domain?  If
> so, is the use
> > > > of Record-Route
> > > > > the correct solution?
> > > > >
> > > > > Steve
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]]On
> Behalf Of
> > > > Jonathan Rosenberg
> > > > > > Sent: Tuesday, December 19, 2000 12:25 AM
> > > > > > To: 'David Shrader'; SIP List
> > > > > > Subject: RE: [SIP] Record-Route and
> REGISTER
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: David Shrader
> [mailto:[email-masked]]
> > > > > > > Sent: Sunday, December 17, 2000 3:40 PM
> > > > > > > To: SIP List
> > > > > > > Subject: [SIP] Record-Route and REGISTER
> > > > > > >
> > > > > > > When using the REGISTER method, however,
> the Contact header
> > > > > > > is NOT used for
> > > > > > > that purpose. The Contact header in the
> Response to a
> > > > > > > REGISTER is simply a
> > > > > > > list of registered contacts and does not
> in fact identify the
> > > > > > > recipient of a
> > > > > > > subsequent request.
> > > > > >
> > > > > > Correct. REGISTER is nearly a separate
> protocol, for all
> > > > intents and
> > > > > > purposes. As specified right now,
> record-routing for
> > > > REGISTER is ambigous.
> > > > > > In any case, record-routing for
> transactions outside of INVITE is
> > > > > > not clear.
> > > > > > What is the the scope of the Route? To
> which set of messages does
> > > > > > it apply?
> > > > > > When can the route be purged? These issues
> must be
> > > > resolved as well, and
> > > > > > they are much harder.
> > > > > >
> > > > > > The solution to your specific problem is
> for the UAC and
> > > > UAC to use RR in
> > > > > > REGISTER instead. So:
> > > > > >
> > > > > > 1. A UAC inserts a REcord-route into the
> REGISTER
> > > > pointing to itself, just
> > > > > > like the Contact would look in an INVITE
> > > > > > 2. proxies can record-route
> > > > > > 3. UAS (the registrar, in this case) also
> adds a RR, and reflects
> > > > > > that back
> > > > > > in 200 OK
> > > > > > 4. Route is constructed normally except
> COntact is ignored
> > > > > >
> > > > > >
> > > > > > Kind of a pain to have a special procedure
> for REGISTER,
> > > > I know. In
> > > > > > hindsight, I would have used something
> instead of Contact
> > > > here, but at the
> > > > > > time rfc2543 was being written, the usages
> were 
=== message truncated ===

> ATTACHMENT part 3.8 message/rfc822 
> De: "Steve Donovan" <[email-masked]>
> À: "Jonathan Rosenberg" <[email-masked]>,
> 	"'Pekka Pessi'" <[email-masked]>,
> <[email-masked]>
> CC: "Gonzalo Camarillo"
> <[email-masked]>
> Objet: RE: [SIP] RE: Changin local RTP port without
> a good reason
> Date: Wed, 20 Dec 2000 09:17:12 -0600
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> > Sent: Tuesday, December 19, 2000 12:31 AM
> > To: 'Pekka Pessi'; [email-masked]
> > Cc: Gonzalo Camarillo
> > Subject: RE: [SIP] RE: Changin local RTP port
> without a good reason
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Pekka Pessi [mailto:[email-masked]]
> > > Sent: Monday, December 18, 2000 3:30 AM
> > > To: [email-masked]
> > > Cc: Gonzalo Camarillo
> > > Subject: Re: [SIP] RE: Changin local RTP port
> without a good reason
> > >
> > >
> > > In message <[email-masked]>
> "ext Gonzalo
> > > Camarillo" <[email-masked]>
> writes:
> > > >Of course that sometimes you have to change
> your local
> > > configuration if
> > > >the remote configuration changes... but there
> has to be a good reason
> > > >(like a change of codecs).
> > >
> > > 	When you issue a re-INVITE with a new local
> port number, you are
> > >         proposing a new RTP session.  The remote
> end can not
> > > distinguish
> > >         between packets in the old session and
> new session, unless it
> > >         changes its RTP port, too.
> >
> >
> > Much as I would like to be able to enforce this
> "don't change
> > ports without
> > good reason", I think there are cases where
> implementations will
> > want to do
> > this on each re-invite. As such, I think the
> mechanism in the current 3pcc
> > draft won't work either.
> >
> > An alternative flow has already been proposed
> which does not
> > suffer from the
> > timeout problem, and which does not have this race
> condition:
> >
> > > >  A                Controller            B
> > > >  |  INV  SDP held    |                  | time
> t = 0
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |  200 SDP A1       |                  |
> > > >  |-----------------> |                  |
> > > >  |                   |                  |
> > > >  |       ACK         |                  |
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |                   |  INV no SDP      |
> > > >  |                   |----------------->|  (1)
> > > >  |                   |                  |
> > > >  |                   |  200 SDP B       |
> > > >  |                   |<-----------------|
> > > >  |      INV SDP B    |                  |
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |  200 SDP A2       |                  |
> > > >  |-----------------> |                  |
> > > >  |                   |                  |
> > > >  |                   |  ACK  SDP A2     |
> > > >  |  ACK              |----------------->|
> > > >  |<------------------|                  |
> > > >  |                   |                  |
> > > >  |                   |       RTP        |
> > > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > > >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> > > >  |                   |                  |
> >
> >
> > I'd like to start with this one as the basis for
> continuing
> > discussion/concerns.
> 
> What is the end-user experience with this call? 
> What does the
> user at A do when he gets a call that is on hold and
> hears silence?
> Isn't there a high probability that he will hang up
> while the
> controller is waiting for B to answer?
> 
> In order for this to work, isn't it necessary for
> the controller to
> play some sort of media telling the user to hold on
> while the call
> is being setup?  Either that or A needs to
> understand that it is
> a 3PCC call and know to either not notify the user
> or tell the user
> to wait.
> 
> ---
> Steven R. Donovan
> Architect                           dynamicsoft
> mailto:[email-masked]     5100 Tennyson
> Parkway
> sip:[email-masked]    Plano, Texas
> 75025
> tel:+1-972-473-5469                
> http://www.dynamicsoft.com
> 
> 
> 
> 
> > _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, 
Yahoo! Messenger : http://fr.messenger.yahoo.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip