Subject: [SIP] Re: SIP digest, Vol 1 #616 - 4 msgs

From: rufin soh <[email-masked]>
Date: Fri, 15 Dec 2000 19:39:35 +0100 (CET)

If proxy try to send a 200 ok to UAS but receives a
5xx
(next proxy down). It means according to the draft
that it can't contact this server through proxy B, the
best thing for UAS is to have a checking process, or
to have more detailed sdp.

Plese send more details on this topic I think I will
have such a problem in my Project.

--- [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: Solving the REFER retransmit issue
> (Venkatesh Venkataramanan)
>    2. Proxies modifying SDP (Bernie Hoeneisen)
>    3. Re: Solving the REFER retransmit issue (Brett
> Tate)
>    4. RE: Proxies modifying SDP (Jean-Francois Mule)
> 

> ATTACHMENT part 3.1 message/rfc822 
> Répondre à: "Venkatesh Venkataramanan"
> <[email-masked]>
> De: "Venkatesh Venkataramanan"
> <[email-masked]>
> À: "Brett Tate" <[email-masked]>,
> 	"Sip Mail List" <[email-masked]>
> Objet: Re: [SIP] Solving the REFER retransmit issue
> Date: Fri, 15 Dec 2000 14:07:58 +0530
> 
> I am kind of lost here. How does one provide
> reliability of final responses
> with this scheme?  Say I initiated a refer with
> refer-disposition-response
> as "final" or "notify" or "notify-failure". I am
> assuming that "final" in
> the refer-disposition-response will automatically
> trigger a 200 OK for the
> initial refer so as to prevent the REFER request
> from timing out (so a
> "refer" in the refer-response-disposition is implied
> or should be added
> explicitly to avoid timeouts which we are trying to
> address). But at a later
> time, say the recipient of REFER wants to send a 200
> OK to indicate
> successful completion of the request (or
> alternatively failure of
> completion). How would reliability of this response
> be assured?
> ----- Original Message -----
> From: "Brett Tate" <[email-masked]>
> To: "Sip Mail List" <[email-masked]>
> Sent: Friday, December 15, 2000 9:14 AM
> Subject: Re: [SIP] Solving the REFER retransmit
> issue
> 
> 
> > How about including a parameter or header in REFER
> > which would indicate an ordered request preference
> for
> > when to send 200 response?
> >
> > Refer-Response-Disposition: 1#refer-response-param
> > refer-response-param =
> >  "refer" | "18x-final" | "final" | "notify" |
> "notify-failure" | token
> >
> > "refer" means send 200 when get REFER.
> >
> > "18x-final" means send final response when get 18x
> or final
> > response for method request.
> >
> > "final" means send final response when success or
> failure
> > of method request is determined.
> >
> > "notify" send 200 when get REFER and send NOTIFY
> > with method final response.
> >
> > "notify-failure" send 200 when get REFER and send
> > NOTIFY when a failure of the method request is
> > determined.
> >
> > The 200 response could contain the same header to
> indicate
> > the meaning of the 200.  Notice that the new
> header would
> > only be a preference in request.  If the receiver
> does not
> > support or want to perform "notify", it could try
> the
> > next list preference.  If it doesn't support the
> header or it is
> > not present, it defaults to acting like header
> with "refer".
> >
> > ----- Original Message -----
> > From: "Robert Sparks" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Tuesday, December 12, 2000 12:53 PM
> > Subject: [SIP] Solving the REFER retransmit issue
> >
> >
> > > The presentation of status of REFER and the
> discussion of the
> > > REFER timeout issue is at
> > >
> >
>
http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe
> > > r-02.htm
> > >
> > > Rohan Mahy also proposed an optimization of 2
> where the REFER
> > > was overloaded to also mean SUBSCRIBE - NOTIFYs
> for the progress
> > > of the REFERed action would just happen and
> could be ignored/481'ed
> > > if the the REFERing agent didn't care.
> > >
> > > Jonathan R. stated that 2) requires any agent
> accepting a REFER to
> > > implement being an event server (must implement
> accepting and
> > > managing subscriptions), and this is asking too
> much.
> > >
> > > Discussion?
> > >
> > > RjS
> > >
> > >
> > > _______________________________________________
> > > 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: Fri, 15 Dec 2000 18:55:43 +0200 (EET)
> De: Bernie Hoeneisen <[email-masked]>
> À: [email-masked]
> Objet: [SIP] Proxies modifying SDP
> 
> Hi!
> 
> I have question concerning the case, when SIP
> proxies modify SDP,
> which is AFAIK against SIP principles, isn't it?
> 
> 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).
> 
> Are there any other problems? Any comments are
> appreciated.
> 
> cheers,
>  Bernie
> 
> 
> 
> 

> ATTACHMENT part 3.3 message/rfc822 
> De: "Brett Tate" <[email-masked]>
> À: "Venkatesh Venkataramanan"
> <[email-masked]>,
> 	"Sip Mail List" <[email-masked]>
> Objet: Re: [SIP] Solving the REFER retransmit issue
> Date: Fri, 15 Dec 2000 09:12:28 -0500
> 
> The choice of "final" would act as it does today and
> thus would not be the most desirable choice unless
> the request is expected to finish within 10 retries
> of
> the REFER and the NOTIFY is not supported.
> This would be idle when triggering a BYE or CANCEL.
> It also accommodates Jonathan's concern about
> requiring support of NOTIFY.  Notice that header
> would also be include in the response to explicitly
> state how the 200 should be interpreted.
> 
> The choice of "notify" would basically get a 200
> REFER
> immediately and a NOTIFY once a final response has
> be determined for the REFER triggered method.
> This would be ideal when triggering an INVITE.
> 
> The choice of "notify-failure" would act like
> "notify"
> but the NOTIFY would only be sent only in failure
> situations.  This would be useful in many situations
> but especially useful for failed call transfer
> attempts.
> 
> ----- Original Message -----
> From: "Venkatesh Venkataramanan"
> <[email-masked]>
> To: "Brett Tate" <[email-masked]>; "Sip Mail
> List"
> <[email-masked]>
> Sent: Friday, December 15, 2000 3:37 AM
> Subject: Re: [SIP] Solving the REFER retransmit
> issue
> 
> 
> > I am kind of lost here. How does one provide
> reliability of final
> responses
> > with this scheme?  Say I initiated a refer with
> refer-disposition-response
> > as "final" or "notify" or "notify-failure". I am
> assuming that "final" in
> > the refer-disposition-response will automatically
> trigger a 200 OK for the
> > initial refer so as to prevent the REFER request
> from timing out (so a
> > "refer" in the refer-response-disposition is
> implied or should be added
> > explicitly to avoid timeouts which we are trying
> to address). But at a
> later
> > time, say the recipient of REFER wants to send a
> 200 OK to indicate
> > successful completion of the request (or
> alternatively failure of
> > completion). How would reliability of this
> response be assured?
> > ----- Original Message -----
> > From: "Brett Tate" <[email-masked]>
> > To: "Sip Mail List" <[email-masked]>
> > Sent: Friday, December 15, 2000 9:14 AM
> > Subject: Re: [SIP] Solving the REFER retransmit
> issue
> >
> >
> > > How about including a parameter or header in
> REFER
> > > which would indicate an ordered request
> preference for
> > > when to send 200 response?
> > >
> > > Refer-Response-Disposition:
> 1#refer-response-param
> > > refer-response-param =
> > >  "refer" | "18x-final" | "final" | "notify" |
> "notify-failure" | token
> > >
> > > "refer" means send 200 when get REFER.
> > >
> > > "18x-final" means send final response when get
> 18x or final
> > > response for method request.
> > >
> > > "final" means send final response when success
> or failure
> > > of method request is determined.
> > >
> > > "notify" send 200 when get REFER and send NOTIFY
> > > with method final response.
> > >
> > > "notify-failure" send 200 when get REFER and
> send
> > > NOTIFY when a failure of the method request is
> > > determined.
> > >
> > > The 200 response could contain the same header
> to indicate
> > > the meaning of the 200.  Notice that the new
> header would
> > > only be a preference in request.  If the
> receiver does not
> > > support or want to perform "notify", it could
> try the
> > > next list preference.  If it doesn't support the
> header or it is
> > > not present, it defaults to acting like header
> with "refer".
> > >
> > > ----- Original Message -----
> > > From: "Robert Sparks" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Tuesday, December 12, 2000 12:53 PM
> > > Subject: [SIP] Solving the REFER retransmit
> issue
> > >
> > >
> > > > The presentation of status of REFER and the
> discussion of the
> > > > REFER timeout issue is at
> > > >
> > >
> >
>
http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe
> > > > r-02.htm
> > > >
> > > > Rohan Mahy also proposed an optimization of 2
> where the REFER
> > > > was overloaded to also mean SUBSCRIBE -
> NOTIFYs for the progress
> > > > of the REFERed action would just happen and
> could be ignored/481'ed
> > > > if the the REFERing agent didn't care.
> > > >
> > > > Jonathan R. stated that 2) requires any agent
> accepting a REFER to
> > > > implement being an event server (must
> implement accepting and
> > > > managing subscriptions), and this is asking
> too much.
> > > >
> > > > Discussion?
> > > >
> > > > RjS
> > > >
> > > >
> > > >
> _______________________________________________
> > > > 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.4 message/rfc822 
> De: Jean-Francois Mule <[email-masked]>
> Répondre à: Jean-Francois Mule <[email-masked]>
> À: 'Bernie Hoeneisen' <[email-masked]>,
> [email-masked]
> Objet: RE: [SIP] Proxies modifying SDP
> Date: Fri, 15 Dec 2000 09:29:29 -0800
> 
> 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?'
> 
> > 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
> 
> 
> 
> > _______________________________________________
> 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