The IESG | 10 Nov 06:28 2009
Picon

Protocol Action: 'Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates' to Proposed Standard

The IESG has approved the following document:

- 'Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) 
   X.509 Certificates '
   <draft-ietf-sip-eku-08.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working Group. 

The IESG contact persons are Cullen Jennings and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-08.txt

Technical summary.

This memo documents an extended key usage (EKU) X.509 certificate
extension for 
restricting the applicability of a certificate to use with a Session
Initiation 
Protocol (SIP) service.  As such, in addition to providing rules for SIP 
implementations, this memo also provides guidance to issuers of
certificates for 
use with SIP.

Working group summary.

There is consensus in the working group to publish this document. 

Document Quality

(Continue reading)

The IESG | 10 Nov 21:09 2009
Picon

Protocol Action: 'Connection Reuse in the Session Initiation Protocol (SIP)' to Proposed Standard

The IESG has approved the following document:

- 'Connection Reuse in the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-connect-reuse-14.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working Group. 

The IESG contact persons are Cullen Jennings and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-14.txt

Technical summary.

This document enables a pair of communicating proxies to reuse a
congestion-controlled connection between themselves for sending requests
in the forward and backwards direction.  Because the connection is
essentially aliased for requests going in the 
backwards direction, reuse should be predicated upon both the
communicating endpoints authenticating themselves using X.509 certificates
through TLS.  For this reason, we only consider connection reuse for TLS
over TCP and TLS over SCTP.  A single connection 
should not be reused for the TCP or SCTP transport between two peers, and
this document provides insight into why this is the case.  As a remedy, it
suggests using two TCP connections (or two SCTP associations), each opened
pro-actively towards the recipient by the sender.  Finally, this document
also provides guidelines on connection reuse and virtual SIP servers and
the interaction of connection reuse and DNS SRV lookups in SIP.

Working group summary.
(Continue reading)

Nitin Kapoor | 27 Nov 22:06 2009
Picon

Re-invite Without SDP

Hello All,

I am facing the issue with one of my customer at the time of unhold the call.

I have configured an endpoint that is dropping calls when you place the call on hold.

The network configuration is as follows:

Cisco CallManager using SIP signaling > Cisco Unified Border Element (CUBE) using SIP signaling > MSX communicates SIP to CUBE and h.323 to HT_5850_Egress > PSTN

When a phone on the Cisco CallManager places a call to a user on the PSTN the call goes through successfully. When the phone on the Cisco CallManager places that call on hold, the call gets dropped.

The message I see in the SIP trace is '488 Not acceptable here'.

If we do this same test from the Call Manager to the CUBE to the MSX but instead to L3_Egress so the signalling between the CUBE/MSX/PSTN is SIP the hold option works.

First IWF.. Where this option is not working.

Calling number 763.432.8682
Called number 763.577.3948


On this First Source UA has send the initial invite and which SBC has sent to termination END as h.323 and call is connected successully after the the mesages... Now when my Source UA has sent the invite to put that call on hold it sends "re-invite with SDP with codec g.711u and media attribute = inactive", and call goes on hold successfully, but now whenever they are trying to unhold the call and sending the another "invite without sdp" than my SBC/Nextone is sending "488 unacceptable" to my source UA.

And now the other option SIP(both legs)

Calling number 763.432.8682
Called number 1612.964.8862

Now in this scenario i have both the legs on sip and when my source UA is sending the "invite without SDP" to unhold this call then my my termination end is sending 200 OK with SDP to ACK that call and unhold scenario is working fine.

I am also attaching the call flow for both the scenario. Please help me to find out the root cause of this issue.

Thanks,
Nitin Kapoor
General Telecom


Attachment (Bad Call.pcap): application/octet-stream, 43 KiB
Attachment (Good Call.pcap): application/octet-stream, 114 KiB
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Dale Worley | 28 Nov 07:29 2009

Re: Re-invite Without SDP

On Fri, 2009-11-27 at 16:06 -0500, Nitin Kapoor wrote:
> sending the another "invite without sdp" than my SBC/Nextone is
> sending "488 unacceptable" to my source UA.

If the SBC won't accept an INVITE without SDP, it is operating
incorrectly and you won't be able to get SIP systems to work with it.

Dale

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

yan.chengan | 30 Nov 08:18 2009
Picon

答复: Re-invite Without SDP


The SBC may not support the offer/answer model 200 OK(SDP) for offer and ACK(SDP) for answer.
Then, you can try to use another method to implement Call Hold service, besides using re-INVITE
without SDP for Unhold.

Best regards
Gerald.yan



Nitin Kapoor <nitinkapoorr <at> gmail.com>
发件人:  sip-bounces <at> ietf.org

2009-11-28 05:06

收件人
sip <at> ietf.org
抄送
主题
[Sip] Re-invite Without SDP





Hello All,

I am facing the issue with one of my customer at the time of unhold the call.

I have configured an endpoint that is dropping calls when you place the call on hold.

The network configuration is as follows:

Cisco CallManager using SIP signaling > Cisco Unified Border Element (CUBE) using SIP signaling > MSX communicates SIP to CUBE and h.323 to HT_5850_Egress > PSTN

When a phone on the Cisco CallManager places a call to a user on the PSTN the call goes through successfully. When the phone on the Cisco CallManager places that call on hold, the call gets dropped.

The message I see in the SIP trace is '488 Not acceptable here'.

If we do this same test from the Call Manager to the CUBE to the MSX but instead to L3_Egress so the signalling between the CUBE/MSX/PSTN is SIP the hold option works.

First IWF.. Where this option is not working.

Calling number 763.432.8682
Called number 763.577.3948


On this First Source UA has send the initial invite and which SBC has sent to termination END as h.323 and call is connected successully after the the mesages... Now when my Source UA has sent the invite to put that call on hold it sends "re-invite with SDP with codec g.711u and media attribute = inactive", and call goes on hold successfully, but now whenever they are trying to unhold the call and sending the another "invite without sdp" than my SBC/Nextone is sending "488 unacceptable" to my source UA.

And now the other option SIP(both legs)

Calling number 763.432.8682
Called number 1612.964.8862

Now in this scenario i have both the legs on sip and when my source UA is sending the "invite without SDP" to unhold this call then my my termination end is sending 200 OK with SDP to ACK that call and unhold scenario is working fine.

I am also attaching the call flow for both the scenario. Please help me to find out the root cause of this issue.

Thanks,
Nitin Kapoor
General Telecom

[附件 "Bad Call.pcap" 被 严成安170027/user/zte_ltd 删除][附件 "Good Call.pcap" 被 严成安170027/user/zte_ltd 删除]_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Fred_Stacey | 30 Nov 21:21 2009

Fred Stacey is out of the office.


I will be out of the office starting  11/30/2009 and will not return until
12/01/2009.

For Sun Microsystems related issues, please contact Arnaud Bellens
For 5560 IPT related issues, please contact Simon Binder

Otherwise, if the matter is of an urgent nature, please contact Stephen
Bray or Tim Kostyniuk

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip


Gmane