Subject: [SIP] Re: SIP digest, Vol 1 #620 - 10 msgs

From: rufin soh <[email-masked]>
Date: Mon, 18 Dec 2000 20:07:30 +0100 (CET)

I think for my own that, since proxies and sip servers
are not completely implemented, after a 200 proxy
response, a UAS, instead of using codecs, should
better choose a well known (by proxy)frequency, to
send medias. If not, proxy will remain in a waiting
state, or all the responses could be handled as
"UNKNOWN RESPONSE".According to my fsm implementation,
such responses are removed or just forwarded without
any further process, untill timeout. 

--- [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: Inteligent Codec Selection (Sunitha Kumar)
>    2. Record-Route and REGISTER (David Shrader)
>    3. State transition diagram for INVITE (Piotr S.
> Kossowski)
>    4. Re: 8 bit clean channel (Henning Schulzrinne)
>    5. RE: Proxies modifying SDP (Steve Donovan)
>    6. Re: RE: Changin local RTP port without a good
> reason (Pekka Pessi)
>    7. Re: Bug in 2543bis-02 re: Record-Route (Keith
> Robinson)
>    8. Re: Bug in 2543bis-02 re: Record-Route (Neil
> Deason)
>    9. Re: Proxy Routing Logic (Keith Robinson)
>   10. RE: Proxies modifying SDP
> ([email-masked])
> 

> ATTACHMENT part 3.1 message/rfc822 
> Date: Fri, 15 Dec 2000 16:17:38 -0800
> De: Sunitha Kumar <[email-masked]>
> Affiliation: Cisco Systems
> À: [email-masked]
> CC: [email-masked]
> Objet: Re: [SIP] Inteligent Codec Selection
> 
> check out draft-manyfolks-sip-resource-01.txt.
> it talks about resource reservation.
> 
> 
> 
> 
> [email-masked] wrote:
> 
> > I would like to set up a SIP solution that would
> negotiate to use G.711
> > if there is sufficient bandwith between the two
> endpoints to do so, and would
> > negotiate G.723.1 otherwise.
> >
> > Is there any way to do codec negotiation in such a
> manner?
> >
> > Torrey
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> --
> Sunitha Kumar
> http://www.cisco.com
> 
> 
> 

> ATTACHMENT part 3.2 message/rfc822 
> Date: Sun, 17 Dec 2000 15:40:27 -0500
> De: David Shrader <[email-masked]>
> À: SIP List <[email-masked]>
> Objet: [SIP] Record-Route and REGISTER
> 
> I've been reading the record-route material and am
> considering its general
> application to SIP requests and find that there it
> is not as general as we
> think.
> 
> The mechanism described in the bis-02 relies on the
> interpretation of the
> Contact header only for some messages. That is, the
> text states that the
> Contact header, if included, is appended to the
> Route list. This assumes
> that the Contact header is used only to represent
> the party to which a
> subsequent request along that route would be sent.
> 
> 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.
> 
> Scenario that generated this problem:
>     1. REGISTER is sent from UAC to an outbound
> proxy, addressed to a
>         service provider (i.e., sip:provider.net)
>     2. The proxy inserts a Record-Route header into
> the REGISTER message and
>         routes it to the host for sip:provider.net.
>     3. The server then echoes the Record-Route
> header in the response and
>         several registered Contact headers.
>     4. The UAC then receives the Record-Route. When
> it attempts to refresh
>         its reservation, it cannot follow the rules
> in the bis-02 spec
>         because the Contact header cannot be used as
> a Route header in this
>         case. The message will never get to the
> registrar server because the
>         Request-URI would indicate the received
> record-route header and
>         there is no header to include the
> sip:provider.net URI.
> 
> Any thoughts on a solution?
> 
> I've thought it strange that the UAC is expected to
> add the received Contact
> header to the Route list. Perhaps the solution is
> really that the UAS
> receiving the Record-Route header should add its own
> Contact as the final
> Record-Route. In that way, the UAC doesn't have to
> do anything at all and
> there is no ambiguity due to the overloading of
> Contact header that we have
> done in the spec.
> 
> 
> ----------------------------
> David Shrader
> Master Consultant, Inc.
> [email-masked]
> http://www.EyeForTheFuture.com
> 
> 
> 

> ATTACHMENT part 3.3 message/rfc822 
> Date:   Sun, 17 Dec 2000 23:59:37 +0100
> De: "Piotr S. Kossowski"
> <[email-masked]>
> Affiliation: Warsaw University of Technology -
> Institute of Telecommunications
> À: SIP discussion list <[email-masked]>
> Objet: [SIP] State transition diagram for INVITE
> 
> Dear All,
> 
> I'm a bit confused after long studying of Figure 12
> of the 2543 spec.
> There is State Machine for INVITE method there.
> I'm especially interested in two states: CONFIRMED
> and COMPLETED.
> 
> Please, correct me if I am wrong:
> Being in FAILURE or SUCCESS we can proceed to
> COMPLETED under one
> condition: 32 second of inactivity (no requests from
> UAC).
> Within 32 s. the state machine is waiting for ACK.
> If no ACK, it probably
> means that something must have happend to UAC, and
> "for sure" the Call is
> lost. So, COMPLETED state is common for FAILURE and
> SUCCESS and simply
> means "forget this call". Hovewer, if ACK for
> SUCCESS call (200 OK was
> sent)
> appears State Machine procceds to CONFIRMED state
> and then ALWAYS after
> 32 s. to the COMPLETED (call established,
> transaction successfully
> finalized)
> Thus, My question is:
> 
> 1. Does COMPLETED mean realy two states: either
> COMPLETED_SUCCESS or
>   COMPLETED_FAILURE? 
>   If yes, Maybe lack of ACK witihin 32s in SUCCESS
> state allows machine to 
>   procceed to COMPLETED_SUCCESS ?!
> 
> 2. What for is CONFIRMED state in fact ? No action
> is generated on ACK 
>    in this state, and no (?) "call specific
> variables" are changed on 
>    "32s" transtition to COMPLETED.
> 
> 
> And my last issue. Let's consider the following
> scenario:
> 
> We are currently in SUCCCESS state. So, we are
> waiting for ACK. Sometimes, 
> we can  receive a lost INVITE - we treat it as a
> retransmission and we 
> send, what  we have just sent - 200 OK.
> But, according to 4.2.1 (INVITE description), we
> must regard this 
> transaction as COMPLETED or, at least, we are not
> allowed to response with
> "400 Bad Request" if we have just received another
> INVITE (re-INVITE).
> If this is true, such re-INVITE should invoke new
> instance of state
> machine.
> (or something else should happend, correct me)
> For one call, we have now two state machines. Let
> the second machine
> work. Meanwhile, 32s timeout expired and the first
> machine transited
> to COMPLETED. Beacause I don't know (as mentioned
> above) what COMPLETED
> really means, my question is: what may (should,
> must) happen then:
> - Behaviour the first machine is irrelevant ("the
> newest" machine
>   "hide" all the previous)
> - The second machine should be stopped, because the
> call was broken down.
>   The call is being destroyed.
> - something else ?
> 
> Thanks in advance for your ideas,
> Piotr
> 
> 
> 

> ATTACHMENT part 3.4 message/rfc822 
> Date: Sun, 17 Dec 2000 21:00:18 -0500
> De: Henning Schulzrinne
> <[email-masked]>
> À: Baniel Uri-CUB001 <[email-masked]>
> CC: "[email-masked]'"
> <[email-masked]>
> Objet: Re: [SIP] 8 bit clean channel
> 
> 
> 
> Baniel Uri-CUB001 wrote:
> > 
> > Hi
> > 
> > What is exactly an 8 bit clean channel? What is a
> 7 bit channel?
> 
> TCP. Email.
> 
> > 
> > Thanjs
> > 
> > Uri
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

> ATTACHMENT part 3.5 message/rfc822 
> De: "Steve Donovan" <[email-masked]>
> À: "Baniel Uri-CUB001" <[email-masked]>,
> 	"'Neil Deason'" <[email-masked]>,
> <[email-masked]>,
> 	<[email-masked]>, <[email-masked]>
> Objet: RE: [SIP] Proxies modifying SDP
> Date: Sun, 17 Dec 2000 21:11:56 -0600
> 
> Although I am having a hard time understanding why
> it would be necessary to
> modify the SDP to cause the call to go through a
> specific gateway, as Neil
> correctly points out, this is likely to be a
> function of a back-to-back UA.
> 
> Why is it not enough to have the proxy route the
> call to the gateway in
> question by changing the request-URI to point to the
> gateway?
> 
> Steve
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> Baniel Uri-CUB001
> > Sent: Friday, December 15, 2000 1:51 PM
> > To: 'Neil Deason'; [email-masked];
> [email-masked];
> > [email-masked]
> > Subject: RE: [SIP] Proxies modifying SDP
> >
> >
> > I see it as the requested way of forcing the media
> stream to go
> > via an 'IP switch' (like the H323 MCU).
> > If a proxy server is not allowed or if it is not
> appropriate for
> > it to touch the SDP element, then is there any
> other way to make
> > sure the media stream goes via our MCU gateway.
> (There could be
> > various of reasons why we would want to have such
> a gateway)
> >
> > What do u think?
> >
> > Uri
> >
> > -----Original Message-----
> > From: Neil Deason [mailto:[email-masked]]
> > Sent: Friday, December 15, 2000 12:30 PM
> > To: [email-masked]; [email-masked];
> [email-masked]
> > Subject: RE: [SIP] Proxies modifying SDP
> >
> >
> >
> > >Bernie Hoeneisen wrote:
> > > > I have question concerning the case, when SIP
> proxies modify SDP,
> > > > which is AFAIK against SIP principles, isn't
> it?
> > >I do not think so.
> > >Why is that *against* SIP principles?  What
> principles?'
> >
> > The fundamental concept that payloads are opaque
> to SIP Proxy
> > Servers. To do this sort of thing you probably
> want to use a
> > back to back UA.
> >
> > Cheers,
> > Neil.
> > --
> > Ubiquity Software, UK                   
> www.ubiquity.net
> >
> > > > In the concrete case, proxies would be able to
> remove certain codecs
> > > > from the INVITE messages, depending on the
> current policy in the
> > > > network. (The UAS gets a subset of the codecs,
> which were originally
> > > > sent by the UAC.)
> > > > What impact does such a proxy behavior have to
> SIP? I can think of
> > > > problems with authentication and message
> integrity checking (UAC signs
> > > > message with its private key).
> > >It certainly depends on the security mechanism
> used.  For e.g., with the
> > >simple basic md5, it does not cause any issue.
> > >
> > >Jean-Francois
> >
> >
>
_________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at
> http://www.hotmail.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.6 message/rfc822 
> À: <[email-masked]>
> CC: Gonzalo Camarillo
> <[email-masked]>
> Objet: Re: [SIP] RE: Changin local RTP port without
> a good reason
> De: Pekka Pessi <[email-masked]>
> Date: 18 Dec 2000 10:29:42 +0200
> 
> 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.
> 
> >If my local configuration is too dependant on the
> other party's
> >configuration the negotiation ends up in an
> infinite loop.
> 
>         There is always a request and a
> corresponsing response.  Depending
>         on previous response is not sensible, in my
> opinion.
> 
>                                         Pekka
> 
> 

> ATTACHMENT part 3.7 message/rfc822 
> De: "Keith Robinson" <[email-masked]>
> À: Billy Biggs <[email-masked]>
> CC: Jean-Francois Mule <[email-masked]>,
> 	Billy Biggs <[email-masked]>
> Date: Mon, 18 Dec 2000 10:08:47 +0000
> Objet: Re: [SIP] Bug in 2543bis-02 re: Record-Route
> 
> 
> 
> I believe that the way the text on the construction
> of the Route headers is
> worded will lead to
> faulty behaviour as follows:
> 
> In 6.35.2 (construction of Route header) the text
> says
> 
> "A UA builds the Route header field for subsequent
> requests from the
> Record-Route header fields
> received in either a response or a request"
> 
> This implies that a UA will build a new Route every
> time a Record-Route header
> is present in
> a request or a response, not just for the initial
> INVITE. Therefore, coupled
> with the prior text
> about a proxy adding itself to every request is only
> SHOULD not MUST, a proxy
> which assumes that
>  the Route will persist until the end of call leg
> and doesn't add itself to
> subsequent requests will be
> excluded from the path if other proxies do add
> themselves on subsequent requests
> thereby causing
> a UA to reconstruct the Route header, which would
> break the rule that the path
> is persistent until the
> end of the call leg.
> 
> That said, I have read other memos on the list
> (can't remember which, but they
> are there) where the author
> has implied that a proxy can take itself out of the
> path, which in the above
> scenario would be by excluding
> itself on subsequent requests.
> 
> Perhaps there are two interpretations out there, one
> where a proxy stays in for
> good and one where a
> proxy stays in until it excludes itself; whichever
> is correct, the spec is
> ambiguous as it seems to try and
> support both at the same time. It can't, its one or
> the other.
> 
> Regards,
> 
> K. Robinson
> 
> 
> 
> 
> 
> 
> 
> Billy Biggs <[email-masked]> on 15/12/2000
> 19:52:14
>                                                     
>                            
>                                                     
>                            
>                                                     
>                            
> 
> 
>                                                     
>          
>                                                     
>          
>                                                     
>          
>  To:      Jean-Francois Mule <[email-masked]>   
>          
>                                                     
>          
>  cc:      Billy Biggs <[email-masked]>(bcc:
> Keith    
>           Robinson/MAIN/MC1)                        
>          
>                                                     
>          
>                                                     
>          
>                                                     
>          
>  Subject: Re: [SIP] Bug in 2543bis-02 re:
> Record-Route        
>                                                     
>          
> 
> 
> 
> 
> 
> 
> 
> Jean-Francois Mule ([email-masked]):
> 
> > Independently of the Record-Route discussions, the
> 2543bis-02 (dated
> > 11-24-00) has a small issue:
> >
> > In the same section 6.35.1 of 2543bis-02, it is
> stated:
> > "a request route, once established, persists until
> the end of the call
> > leg, *regardless of whether the Record-Route
> header is present in
> > subsequent requests.*"
> > ...
> > "Note that proxy servers have to add Record-Route
> headers to each
> > request *as long as* they want to be "visited" by
> the next request for
> > the call leg." The persistence of the record-route
> is confusing.  The
> > suggestion is to just remove the note.
> 
>   The statement is correct: The Route persists until
> the end of the call
> leg regardless.  Proxies may not ever leave the
> Route for a call-leg.
> The only thing that can be updated is the Contact
> address at the far
> end.
> 
>   That said, proxies must still add a Record-Route
> header, just to make
> the protocol more explicit.
> 
>   Is there some other statement in the bis which
> makes this confusing?
> Hopefully when this is re-written it will all become
> clearer.
> 
> --
> Billy Biggs, 3Com               Email:
> [email-masked]
> http://www.div8.net/billy/      Phone:
> [email-masked]
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> 
> 
> 

> ATTACHMENT part 3.8 message/rfc822 
> Date: Mon, 18 Dec 2000 10:22:22 +0000
> De: Neil Deason <[email-masked]>
> Affiliation: Ubiquity Software Corporation Limited
> À: Keith Robinson <[email-masked]>
> CC: Billy Biggs <[email-masked]>,
> 	Jean-Francois Mule <[email-masked]>,
> [email-masked]
> Objet: Re: [SIP] Bug in 2543bis-02 re: Record-Route
> 
> I wouldn't pay too much attention to the present
> Record-Route
> text. 
> This problem area was discussed in some detail at
> the recent
> bakeoff 
> + IETF. There should shortly be revised text from
> Jonathan R 
> which will be simpler, cleaner and work.
> 
> Cheers,
> Neil.
> -- 
> Ubiquity Software Corporation, UK       
> http://www.ubiquity.net
> 
> Keith Robinson wrote:
> > 
> > I believe that the way the text on the
> construction of the Route headers is
> > worded will lead to
> > faulty behaviour as follows:
> > 
> > In 6.35.2 (construction of Route header) the text
> says
> > 
> > "A UA builds the Route header field for subsequent
> requests from the
> > Record-Route header fields
> > received in either a response or a request"
> > 
> > This implies that a UA will build a new Route
> every time a Record-Route header
> > is present in
> > a request or a response, not just for the initial
> INVITE. Therefore, coupled
> > with the prior text
> > about a proxy adding itself to every request is
> only SHOULD not MUST, a proxy
> > which assumes that
> >  the Route will persist until the end of call leg
> and doesn't add itself to
> > subsequent requests will be
> > excluded from the path if other proxies do add
> themselves on subsequent requests
> > thereby causing
> > a UA to reconstruct the Route header, which would
> break the rule that the path
> > is persistent until the
> > end of the call leg.
> > 
> > That said, I have read other memos on the list
> (can't remember which, but they
> > are there) where the author
> > has implied that a proxy can take itself out of
> the path, which in the above
> > scenario would be by excluding
> > itself on subsequent requests.
> > 
> > Perhaps there are two interpretations out there,
> one where a proxy stays in for
> > good and one where a
> > proxy stays in until it excludes itself; whichever
> is correct, the spec is
> > ambiguous as it seems to try and
> > support both at the same time. It can't, its one
> or the other.
> > 
> > Regards,
> > 
> > K. Robinson
> 
> 

> ATTACHMENT part 3.9 message/rfc822 
> De: "Keith Robinson" <[email-masked]>
> À: Billy Biggs <[email-masked]>
> CC: SIP List <[email-masked]>
> Date: Mon, 18 Dec 2000 11:01:19 +0000
> Objet: Re: [SIP] Proxy Routing Logic
> 
> 
> 
> For the first case, couldn't this be the result of a
> roaming UA using source
> routing to get the
> initial INVITE to its home domain proxy to do the
> actual routing (perhaps the
> user has
> originating call features registered that they wish
> to use); in which case I
> would expect the
> behaviour in 2 to take place.
> 
> Regards,
> 
> K. Robinson.
> 
> 
> 
> 
> 
> 
> 
> Billy Biggs <[email-masked]> on 15/12/2000
> 20:26:49
>                                                     
>                            
>                                                     
>                            
>                                                     
>                            
> 
> 
>                                                     
>          
>                                                     
>          
>                                                     
>          
>  To:      SIP List <[email-masked]>        
>          
>                                                     
>          
>  cc:      (bcc: Keith Robinson/MAIN/MC1)            
>          
>                                                     
>          
>                                                     
>          
>                                                     
>          
>  Subject: [SIP] Proxy Routing Logic                 
>          
>                                                     
>          
> 
> 
> 
> 
> 
> 
> 
>   If a proxy at proxy.com receives a request with a
> Request-URI of:
> 
>             
> sip:[email-masked];maddr=proxy.com
> 
> 
>   Should the proxy:
> 
>   1. Return a 404.
>   2. Proxy the message to [email-masked],
> ditching the maddr
>      parameter.
> 
> 
>   Now say there is a populated Route header.  Should
> the proxy:
> 
>   1. Replace the Request-URI with the first Route
> and proxy.
>   2. Return a 404.
>   3. Proxy the message to [email-masked],
> ditching the maddr
>      parameter (and not popping the Route).
> 
> 
>   I think it should do 1 for each case.  Thoughts?
> 
> --
> Billy Biggs, 3Com               Email:
> [email-masked]
> http://www.div8.net/billy/      Phone:
> [email-masked]
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> 
> 
> 

> ATTACHMENT part 3.10 message/rfc822 
> De: [email-masked]
> Date: Mon, 18 Dec 2000 14:18 -0000
> À: "Steve Donovan" <[email-masked]>,
> 	"Baniel Uri-CUB001" <[email-masked]>,
> 	"Neil Deason" <[email-masked]>,
> <[email-masked]>,
> 	<[email-masked]>, <[email-masked]>
> Objet: RE: [SIP] Proxies modifying SDP
> 
> I suspect the original writer refers to some sort of
> media gateway 
> that is not  SIP enabled. Therefore one could not
> simply  proxy the 
> call to the gateway. 
> 
> ----Original Message-----
>    >From:     	Steve Donovan
> <[email-masked]>
>    >To:         	Baniel Uri-CUB001
> <[email-masked]>; 'Neil 
> Deason' <[email-masked]>;
> <[email-masked]>; 
> <[email-masked]>; <[email-masked]>
>    >Cc:         	
>    >Subj:     	RE: [SIP] Proxies modifying SDP
>    >Reply To:     	
>    >Sent:    	Sunday, December 17, 2000 9:13 PM
>    >
>    >Although I am having a hard time understanding
> why it would be 
> necessary to
>    >modify the SDP to cause the call to go through a
> specific gateway, 
> as Neil
>    >correctly points out, this is likely to be a
> function of a 
> back-to-back UA.
>    >
>    >Why is it not enough to have the proxy route the
> call to the 
> gateway in
>    >question by changing the request-URI to point to
> the gateway?
>    >
>    >Steve
>    >
>    >> -----Original Message-----
>    >> From: [email-masked]
>    >> [mailto:[email-masked]]On
> Behalf Of Baniel 
> Uri-CUB001
>    >> Sent: Friday, December 15, 2000 1:51 PM
>    >> To: 'Neil Deason'; [email-masked];
> [email-masked];
>    >> [email-masked]
>    >> Subject: RE: [SIP] Proxies modifying SDP
>    >>
>    >>
>    >> I see it as the requested way of forcing the
> media stream to go
>    >> via an 'IP switch' (like the H323 MCU).
>    >> If a proxy server is not allowed or if it is
> not appropriate for
>    >> it to touch the SDP element, then is there any
> other way to make
>    >> sure the media stream goes via our MCU
> gateway. (There could be
>    >> various of reasons why we would want to have
> such a gateway)
>    >>
>    >> What do u think?
>    >>
>    >> Uri
>    >>
>    >> -----Original Message-----
>    >> From: Neil Deason
> [mailto:[email-masked]]
>    >> Sent: Friday, December 15, 2000 12:30 PM
>    >> To: [email-masked]; [email-masked]; 
> [email-masked]
>    >> Subject: RE: [SIP] Proxies modifying SDP
>    >>
>    >>
>    >>
>    >> >Bernie Hoeneisen wrote:
>    >> > > I have question concerning the case, when
> SIP proxies modify 
> SDP,
>    >> > > which is AFAIK against SIP principles,
> isn't it?
>    >> >I do not think so.
>    >> >Why is that *against* SIP principles?  What
> principles?'
>    >>
>    >> The fundamental concept that payloads are
> opaque to SIP Proxy
>    >> Servers. To do this sort of thing you probably
> want to use a
>    >> back to back UA.
>    >>
>    >> Cheers,
>    >> Neil.
>    >> --
>    >> Ubiquity Software, UK                   
> www.ubiquity.net
>    >>
>    >> > > In the concrete case, proxies would be
> able to remove 
> certain codecs
>    >> > > from the INVITE messages, depending on the
> current policy in 
> the
>    >> > > network. (The UAS gets a subset of the
> codecs, which were 
> originally
>    >> > > sent by the UAC.)
>    >> > > What impact does such a proxy behavior
> have to SIP? I can 
> think of
>    >> > > problems with authentication and message
> integrity checking 
> (UAC signs
>    >> > > message with its private key).
>    >> >It certainly depends on the security
> mechanism used.  For e.g., 
> with the
>    >> >simple basic md5, it does not cause any
> issue.
>    >> >
>    >> >Jean-Francois
>    >>
>    >> 
>
_______________________________________________________________________
> __
>    >> Get Your Private, Free E-mail from MSN Hotmail
> at 
> http://www.hotmail.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
>    >>
>    >
>    >
>    >_______________________________________________
>    >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
> 
> 

___________________________________________________________
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