Hello Nathalie, (eyeBeam 1.1 3010n stamp 19039 ) does offer EVRC Audio codec.
Cheers Vihang ------------------------------------------------------------- Message: 1 Date: Fri, 29 Sep 2006 15:21:58 +0200 From: "Le Mouellic, Nathalie" <[EMAIL PROTECTED]> Subject: [Sip-implementors] EVRC SIP Phone To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="US-ASCII" Hi, I am implementing EVRC Speech codec for 3gpp2 network on my platform but I haven't find an EVRC capable SIP Phone. Does someone have such phone available? Thanks & regards, Nathalie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 29, 2006 2:08 PM To: [email protected] Subject: Sip-implementors Digest, Vol 42, Issue 34 Send Sip-implementors mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip-implementors digest..." Today's Topics: 1. EVRC SIP Phone (Le Mouellic, Nathalie) 2. Re: [Sip] PRACK query ([EMAIL PROTECTED]) 3. Re: (no subject) (kasturi Narayanan) 4. Re: [Sip] PRACK query (Christer Holmberg) 5. Re: Releasing a Call by B2BUserAgent when one of the endpoints reboots during the active call ([EMAIL PROTECTED]) 6. Re: REGISTERing on behalf of someone (Martin Larochelle) 7. Which final responses should have ACK (Andreas Bystr?m) ---------------------------------------------------------------------- Message: 1 Date: Fri, 29 Sep 2006 15:21:58 +0200 From: "Le Mouellic, Nathalie" <[EMAIL PROTECTED]> Subject: [Sip-implementors] EVRC SIP Phone To: <[email protected]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="US-ASCII" Hi, I am implementing EVRC Speech codec for 3gpp2 network on my platform but I haven't find an EVRC capable SIP Phone. Does someone have such phone available? Thanks & regards, Nathalie ------------------------------ Message: 2 Date: Fri, 29 Sep 2006 19:07:48 +0530 From: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] [Sip] PRACK query To: "Christer Holmberg \(JO/LMF\)" <[EMAIL PROTECTED]> Cc: [email protected], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="US-ASCII" SDP in 1xx response and 200 OK can be different because of early media announcements and actual calle connected. If 200 OK SDP will be same, then how can early media will be differentiated with regular session (basically early media is used for announcements and 200 OK will tell the actual callee connected) Regards, Udit "Christer Holmberg \(JO/LMF\)" <[EMAIL PROTECTED]> 09/28/2006 07:46 PM To Udit Goyal/C/US/[EMAIL PROTECTED], <[email protected]> cc [email protected] Subject RE: [Sip] PRACK query Hi, >Please let me know if my understanding is correct for regular session offer-answer when PRACK is used: > >For INVITE containing SDP, and if offer answer done in the using reliable 183 response for early media, 200 OK response SDP will have an answer for the >regular session, so 200 OK SDP will be answer to the offer sent in initial SDP. Yes. Of course, since you have already received the answer reliably, you really don't need to care about the SDP in 200 OK, but according to the rules it should be the same as previously sent in 18x. >Similarly, if INVITE does not have SDP, and if offer-answer done using PRACK, still 200 OK will contain the regular session offer and answer will be >present n the ACK message. I would assume so, yes. But, again, you don't really need to care. >Similarly, if UPDATE is used for offer-answer before call is connected, it will not affect the regular session offer-answer, it will be taken care by >initial INVITE , final 200 OK and ACK message. I don't know what you mean by "not affect". If you send an offer in INVITE, and receives an answer in a reliable 18x, the offer/answer exchange in UPDATE will then replace the one previously done. But, yes, the SDP you get in the 200 OK should still be the same that you got in 18x, even if you have performed offer/answer exchanges after that. At least this is how I understand it - but you can never be sure when it comes to offer/answer :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip ------------------------------ Message: 3 Date: Fri, 29 Sep 2006 08:55:54 -0500 From: "kasturi Narayanan" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] (no subject) To: " 'Andreas Bystr?m' " <[EMAIL PROTECTED]>, <[email protected]> Cc: 'Pierre Desaulty' <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" All Responses to Non-Invite (Subscribe Register etc) do not have ACK. Only Invite Transaction is a three way handshake which mandates an ACK for any response. Kasturi -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Bystr?m Sent: Friday, September 29, 2006 7:32 AM To: [email protected] Cc: 'Pierre Desaulty' Subject: [Sip-implementors] (no subject) Whats the expected behavior for a AUC when receiving a 401 or 407? My guess was that all 4xx responses should be responded with an ACK from the UA. But looking at the exaples of RFC3665, it looks like a 401 does not have an ACK but 407 does require an ACK. Is there any note about this in rfc3261, that 401 and 407 should be treated different? Maybe it has to do wich type of request that is submitted (in rfc3665 agian, register and 401 has no ack, invite and 407 has an ack)? Regards, // Andreas _______________________________ Andreas Bystr?m Software Engineer Teligent AB Konsul Jonssons v?g 17 P.O. Box 213 SE 14923 Nyn?shamn mail: [EMAIL PROTECTED] web: www.teligent.se <http://www.teligent.se/> phone: +46 (0)8 4101 7221 mobile: +46 (0)733 1172 21 fax: +46 (0)8 520 193 36 _______________________________ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 4 Date: Fri, 29 Sep 2006 17:32:40 +0300 From: "Christer Holmberg" <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] [Sip] PRACK query To: [EMAIL PROTECTED] Cc: [email protected], [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8 Hi, If you want to use a different SDP in 200 OK you need to use a different To tag. You can not "update" an answer within the same dialog by sending a new SDP in 200 OK. Regards, Christer ________________ Reply Header ________________ Subject: RE: [Sip] PRACK query Author: [EMAIL PROTECTED] Date: 29th September 2006 7:07:48 pm SDP in 1xx response and 200 OK can be different because of early media announcements and actual calle connected. If 200 OK SDP will be same, then how can early media will be differentiated with regular session (basically early media is used for announcements and 200 OK will tell the actual callee connected) Regards, Udit "Christer Holmberg \(JO/LMF\)" <[EMAIL PROTECTED]> 09/28/2006 07:46 PM To Udit Goyal/C/US/[EMAIL PROTECTED], <[email protected]> cc [email protected] Subject RE: [Sip] PRACK query Hi, >Please let me know if my understanding is correct for regular session offer-answer when PRACK is used: > >For INVITE containing SDP, and if offer answer done in the using reliable 183 response for early media, 200 OK response SDP will have an answer for the >regular session, so 200 OK SDP will be answer to the offer sent in initial SDP. Yes. Of course, since you have already received the answer reliably, you really don't need to care about the SDP in 200 OK, but according to the rules it should be the same as previously sent in 18x. >Similarly, if INVITE does not have SDP, and if offer-answer done using PRACK, still 200 OK will contain the regular session offer and answer will be >present n the ACK message. I would assume so, yes. But, again, you don't really need to care. >Similarly, if UPDATE is used for offer-answer before call is connected, it will not affect the regular session offer-answer, it will be taken care by >initial INVITE , final 200 OK and ACK message. I don't know what you mean by "not affect". If you send an offer in INVITE, and receives an answer in a reliable 18x, the offer/answer exchange in UPDATE will then replace the one previously done. But, yes, the SDP you get in the 200 OK should still be the same that you got in 18x, even if you have performed offer/answer exchanges after that. At least this is how I understand it - but you can never be sure when it comes to offer/answer :) Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip ------------------------------ Message: 5 Date: Fri, 29 Sep 2006 11:29:13 -0400 From: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Releasing a Call by B2BUserAgent when one of the endpoints reboots during the active call To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [email protected] Message-ID: <[EMAIL PROTECTED] COM> Content-Type: text/plain; charset=US-ASCII I would recommend session timer (RFC 4028). The two UAs (your B2BUA and the other endpoint), and any proxies in the signaling path, negotiate to agree on the session refresh interval and who will send the refresh request. Then, periodically one UA sends a refresh request (re-INVITE or UPDATE) and the other sends a response. If the timer times out with no refresh request or response seen, those remaining alive can kill the call. There are other mechanisms a UA can use, too. I've seem some that send a periodic INFO request to the other UA, and if they don't get a response, they kill the call. And any UA, B2BUA or not, can periodically send a re-INVITE or UPDATE as a session refresh request. Even if nobody else on the signaling path supports 4028. But I like 4028 because if both UAs support it, they can agree on how often to do a session refresh and who will do it. Dave Robbins Verizon Laboratories 40 Sylvan Rd. Waltham, MA 02451-1128 781 466 4188 [EMAIL PROTECTED] st.net Sent by: To sip-implementors- [email protected] [EMAIL PROTECTED] cc ia.edu Subject Re: [Sip-implementors] Releasing a 09/29/06 08:09 AM Call by B2BUserAgent when one of the endpoints reboots during the active call From: HemalShah <[EMAIL PROTECTED]> I have to implement Releasing of the call from B2BUserAgent when one of the endpoints involved in the call is reboots. I want to know that, Is there any draft or RFC available for this? Or what should be the best way to implement this. In general, a SIP UA can't tell if the UA at the other end has ceased participating in a dialog unless the far-end UA sends a BYE. But if both UAs support the "session timer" mechanism, a UA can determine if the other UA has stopped responding. Some B2BUAs and PSTN gateways will assume that if the other UA stops sending RTP for long enough, the other UA has abandoned the dialog, but this method is not reliable and I've heard of B2BUAs that hang up when the other UA puts the call on hold. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ------------------------------ Message: 6 Date: Fri, 29 Sep 2006 12:24:58 -0400 From: Martin Larochelle <[EMAIL PROTECTED]> Subject: Re: [Sip-implementors] REGISTERing on behalf of someone To: [email protected] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed [EMAIL PROTECTED] wrote: > From: [EMAIL PROTECTED] > > My application, which is not really related to either pennytel or voxalot, > can successfully register with pennytel (it handles the 401 authentication > reply by providing the valid pennytel credentials), however, because my > application's server address is different to the contact server address, > pennytel thinks that my application is a firewall/ATA. All INVITEs now go > back to my machine's address for forwarding to the contact, however I > don't want to have to handle INVITES... I just want to perform the > REGISTER and get out of the picture and (ideally) get pennytel to send the > INVITEs directly to [EMAIL PROTECTED] > >It sounds like the Registrar is broken. If the REGISTER is properly >authenticated, it should take the Contact at face value, and not add a >Route to ensure that the request goes to the Contact via the UAC that >submitted the REGISTER. Hmmm, that's just completely broken. If the >Contact is behind a NAT, it is responsible for determining its address >as it appears to the Proxy, and using that as its Contact address. > > Either that or the Contact header your application is sending contains its local IP address. If a 3rd party want to add/refresh a binding on the behalf of someone else, it most put the AoR in the To header and the contact location in the Contact header. -- Martin Larochelle Software Developer Macadamian Technologies martin AT macadamian.com (613) 739-5976 ext.149 www.macadamian.com The information contained in this email is intended by Macadamian Technologies Inc. for the use by the named individual or entity to which it is addressed and may contain information that is privileged or confidential. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee expressly permitted in this email. If you have received this email in error, please delete it without copying or forwarding it, and notify the sender. ------------------------------ Message: 7 Date: Fri, 29 Sep 2006 21:07:54 +0200 From: Andreas Bystr?m <[EMAIL PROTECTED]> Subject: [Sip-implementors] Which final responses should have ACK To: <[email protected]> Cc: 'Pierre Desaulty' <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" Sorry, forgot to fill in the Subject field... Katsuri, do you have a reference in RFC3261 where I can find this info? Regards, // Andreas > -----Original Message----- > From: kasturi Narayanan [mailto:[EMAIL PROTECTED] > Sent: Friday, September 29, 2006 3:56 PM > To: 'Andreas Bystr?m'; [email protected] > Cc: 'Pierre Desaulty' > Subject: RE: [Sip-implementors] (no subject) > > > All Responses to Non-Invite (Subscribe Register etc) do not have ACK. > Only Invite Transaction is a three way handshake which mandates an ACK > for any response. > > Kasturi > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andreas > Bystr?m > Sent: Friday, September 29, 2006 7:32 AM > To: [email protected] > Cc: 'Pierre Desaulty' > Subject: [Sip-implementors] (no subject) > > Whats the expected behavior for a AUC when receiving a 401 or 407? > > My guess was that all 4xx responses should be responded with an ACK > from the UA. But looking at the exaples of RFC3665, it looks like a > 401 does not have an ACK but 407 does require an ACK. Is there any > note about this in rfc3261, that 401 and > 407 should be treated different? Maybe it has to do wich type of > request that is submitted (in rfc3665 agian, register and > 401 has no ack, invite and 407 has an ack)? > > Regards, > // Andreas > > _______________________________ > > Andreas Bystr?m > Software Engineer > > Teligent AB > Konsul Jonssons v?g 17 > P.O. Box 213 > SE 14923 Nyn?shamn > > mail: [EMAIL PROTECTED] > web: www.teligent.se <http://www.teligent.se/> > phone: +46 (0)8 4101 7221 > mobile: +46 (0)733 1172 21 > fax: +46 (0)8 520 193 36 > _______________________________ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listin> fo/sip-implementors > > > ------------------------------ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors End of Sip-implementors Digest, Vol 42, Issue 34 ************************************************ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
