Subject: [SIP] Re: SIP digest, Vol 1 #622 - 2 msgs

From: rufin soh <[email-masked]>
Date: Tue, 19 Dec 2000 15:17:04 +0100 (CET)

May be I am mistaking but I think that, SIP must
remain a very light protocol. According to me you are
trying to implement a sort of UAS, in proxy, and I
don't know if you are working on the first version, if
so,it is better to first work with as less codecs as
possible.
2. Proxy must not issue, a request of its own other
than ACK, or CANCEL, he just have to forward(lets say
a 200) response, on receiving an INVITE, and hence,
wait for communication to be established.
3. Make your UAS as simple as possible: don't try to
make your tests with a UAS running on the same
computer with a proxy. According to the draft, After a
200 response, the next step for proxy should be to
wait for the communication stream, all other response
or request could modify the state of the automate.

--- [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: SIP digest, Vol 1 #620 - 10 msgs
> (=?iso-8859-1?q?rufin=20soh?=)
>    2. RE: Proxies modifying SDP (Baniel Uri-CUB001)
> 

> ATTACHMENT part 3.1 message/rfc822 
> Date: Mon, 18 Dec 2000 20:07:30 +0100 (CET)
> De: rufin soh <[email-masked]>
> À: [email-masked]
> Objet: [SIP] Re: SIP digest, Vol 1 #620 - 10 msgs
> 
> 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.
> > 
> 
=== message truncated ===

> ATTACHMENT part 3.2 message/rfc822 
> De: Baniel Uri-CUB001 <[email-masked]>
> À: "'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: Mon, 18 Dec 2000 19:05:17 -0600
> 
> 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
> 
> 
> 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
> 
> 

___________________________________________________________
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