Dale.Worley | 1 Jul 03:37 2008
Picon
Picon

Re: Progress on draft-jesske-sipping-etsi-ngn-reason-03

   From: "Jesske, R" <R.Jesske <at> telekom.de>

   REQ-GEN-1:  

      All simulation services must provide interoperability with the 
      PSTN/ISDN. By interoperability we mean that, in the case that a 
      simulation or supplementary service is provided to one of the users 
      when one of the endpoints is located in the PSTN and the other is 
      located in the NGN IMS network, the user should receive the service 
      without any degradation as if the service were provided in the native
      network. 

I'll warn you that this requirement statement is (from a SIP point of
view) extremely vague, and you're not likely to get any traction from
it.

   So the Reason header within responses will help to fulfil this there are
   certain cause values that are very specific for services. Like the
   example within the draft pointing to the Closed User Group service.

It seems to me that what you are seeking is not the ability to carry a
certain list of ISUP cause values (e.g., the ones listed in the I-D),
but rather a means for carrying the ISUP cause value itself, a way to
tunnel the ISUP cause value.in SIP, for SS7-SIP-SS7 double-gatewaying.

And if that's what you want, you should state it as a requirement.

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
(Continue reading)

Qian Sun | 1 Jul 04:13 2008

Re: Publish a different status for different contacts

Hi,

For example, the presence source could publish:
<presence>
  <tuple>
     <status>
       <basic>open</basic>
     </status>
     <class>A</class>
  </tuple>
</presence>

And set the presence rules like:
<transformations>
   <provide_services>
     <class>A</class>
   </provide_services>
</transformations>

Qian

> -----Original Message-----
> From: vasantha.kumar <at> wipro.com [mailto:vasantha.kumar <at> wipro.com]
> Sent: Monday, June 30, 2008 8:28 PM
> To: sipping <at> ietf.org
> Cc: Dale.Worley <at> comcast.net; sunqian <at> huawei.com
> Subject: RE: [Sipping] Publish a different status for different contacts
> 
> Hi,
> 
(Continue reading)

Jesske, R | 1 Jul 14:12 2008
Picon

Re: Progress on draft-jesske-sipping-etsi-ngn-reason-03

I'll try to reword the requirements:

REQ-1:
It should be possible to support PSTN-SIP-PSTN scenarios where the reason of a call release can be
transferred though the SIP domain without any loss of information and no change of reason. 
REQ-2: 
It should be possible to provide correct announcements to a SIP user based on the reason for call clearing
within the PSTN network or the PSTN user.

Is that better?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipping-bounces <at> ietf.org 
> [mailto:sipping-bounces <at> ietf.org] Im Auftrag von 
> Dale.Worley <at> comcast.net
> Gesendet: Dienstag, 1. Juli 2008 03:37
> An: sipping <at> ietf.org
> Betreff: Re: [Sipping] Progress on 
> draft-jesske-sipping-etsi-ngn-reason-03
> 
> 
>    From: "Jesske, R" <R.Jesske <at> telekom.de>
> 
>    REQ-GEN-1:  
> 
>       All simulation services must provide interoperability with the 
(Continue reading)

Paul Kyzivat | 1 Jul 15:35 2008
Picon

Current status of response to 3gpp Liaison Statement on offer/answer procedures

Some time ago 3gpp requested liaison regarding offer/answer procedures. 
The liaison document may be found at:

https://datatracker.ietf.org/liaison/444/

Information about the discussion can be found at:

http://www.ietf.org/mail-archive/web/sipping/current/msg15771.html

Some of us (especially Christer and I) have been discussing this 
privately. Mary has asked for a clarification of the current status to 
the group. This is my attempt to do so:

To summarize the issue:

- Assume one issues a re-INVITE,
- and that results in multiple offer/answer exchanges
   (via PRACK and UPDATE) prior to the completion of
   the re-INVITE,
- and then the re-INVITE *fails* (response >= 300)

Then in what state is the session left, with regard to SDP and media 
sessions?

None of the RFCs clearly cover this case. The offer/answer draft touched 
on it, but is not normative and so could not resolve it.

We have concluded that there are two plausible ways of treating this:

MULTI-OA-TRANSACTION:
(Continue reading)

Dawes, Peter, VF-Group | 1 Jul 17:29 2008

Re: New I-Ds:draftdraft-dawes-sipping-debug-event-00and draft-dawes-sipping-debug-id-00

Thanks Dale for the thought-provoking questions and thanks Keith for the
information about how the decision is made between standards track and
informational.

In response to the questions:

>- Your example does not show how the event package is used to retrieve
the logging information.  (I assume that is its purpose.)

It is true that the example and the drafts do not show retrieving
logging information. The drafts focus on providing the capability to
centralize debugging configuration at an event package hosted by the
registrar, which allows any SIP entity to take part in debugging of a
given address of record. Once the log files have been generated, I guess
that post processing to correlate log files from all entities is needed
to piece together the sequence of signalling. I wasn't planning to
describe sending and post processing of log files in the drafts.

>- You write "The network administrators configure Alice's UA and the
>   SIP proxy that Alice uses to log SIP signalling the next time she
>   sends an INVITE request."  Looking at the following paragraph, I
>   wonder if you mean, "By subscribing to the debug-event package at
>   Alice's UA and the SIP proxy, the network administrators ..."?
> 
>   Also, it seems that the logging does not apply to "the next time she
>   sends an INVITE request" but "any dialog carrying debug ID A076D1".

I agree that the description was not clear, I have re-written it as: 

   Alice has a SIP client on her laptop, which she has been using for
(Continue reading)

Jeroen van Bemmel | 1 Jul 19:17 2008
Picon

Re: Progress on draft-jesske-sipping-etsi-ngn-reason-03

Roland,

REQ-2 can be satisfied by answering the call in the PSTN and playing the 
correct announcement there. Perhaps there are additional requirements 
that would prohibit such a solution?

Regards,
Jeroen

Jesske, R wrote:
> I'll try to reword the requirements:
>
> REQ-1:
> It should be possible to support PSTN-SIP-PSTN scenarios where the reason of a call release can be
transferred though the SIP domain without any loss of information and no change of reason. 
> REQ-2: 
> It should be possible to provide correct announcements to a SIP user based on the reason for call clearing
within the PSTN network or the PSTN user.
>
> Is that better?
>
> Best Regards
>
> Roland
>
>   
>> -----Ursprüngliche Nachricht-----
>> Von: sipping-bounces <at> ietf.org 
>> [mailto:sipping-bounces <at> ietf.org] Im Auftrag von 
>> Dale.Worley <at> comcast.net
(Continue reading)

Dale.Worley | 1 Jul 20:08 2008
Picon
Picon

Re: Progress on draft-jesske-sipping-etsi-ngn-reason-03

   From: "Jesske, R" <R.Jesske <at> telekom.de>

   I'll try to reword the requirements:

   REQ-1:
   It should be possible to support PSTN-SIP-PSTN scenarios where the
   reason of a call release can be transferred though the SIP domain
   without any loss of information and no change of reason. 

   REQ-2: 
   It should be possible to provide correct announcements to a SIP
   user based on the reason for call clearing within the PSTN network
   or the PSTN user.

   Is that better?

Yes, that is much clearer!

I assume that the ISUP reasons are two-digit codes, and there is no
intrinsic restriction on what two-digit combinations they can be.
That is, for REQ-1, codes 00 through 99 must be supported, even if
they have no assigned meaning now.

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

(Continue reading)

Michael Procter | 1 Jul 21:18 2008
Picon

Re: Progress on draft-jesske-sipping-etsi-ngn-reason-03

Dale Worley wrote:
> I assume that the ISUP reasons are two-digit codes, and there is no
> intrinsic restriction on what two-digit combinations they can be.
> That is, for REQ-1, codes 00 through 99 must be supported, even if
> they have no assigned meaning now.

Not quite.  Q.850 cause values are 7 bits long, and (last time I looked)
approximately half of the 128 values have assigned meanings

One thing that doesn't seem to be mentioned in the draft, but seems
useful if you are trying to achieve REQ-1 is the 'Location' field.  This
is a 4-bit field defining where in the network the specific cause was
generated.  Whilst not something that has an obvious mapping to SIP, it
is presumably useful in the ISUP-SIP-ISUP scenario.

My ISUP knowledge is a good few years out of date now, so someone might
be able to provide corrections to the above.  In particular, I'd be
interested in knowing how widely used the location field really is.

Michael

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

Rockson Li (zhengyli | 2 Jul 03:51 2008
Picon

Re: Current status of response to 3gpp Liaison Statement on offer/answer procedures

Paul,

From my personal experience, I have never seen reliable response with o/a to re-invite,
What I find in real world is there might be only 100Trying between re-INVITE and final response.

I think if UA really need multiple o/a, it just need multiple re-invite/200 or UPDATE/200 pairs, 
It's unnecessary to have reliable response with o/a to re-invite in implementation, 
many vendors would prefer simple mechanism which is clear stated in spec.

Therefore, is there possibility that we exclude  reliable response with o/a to re-invite in SIP o/a framework?

Regards,
-Rockson

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of Paul Kyzivat (pkyzivat)
Sent: Tuesday, July 01, 2008 9:35 PM
To: sipping
Cc: Mary Barnes; Gonzalo Camarillo
Subject: [Sipping] Current status of response to 3gpp Liaison Statement on offer/answer procedures

Some time ago 3gpp requested liaison regarding offer/answer procedures. 
The liaison document may be found at:

https://datatracker.ietf.org/liaison/444/

Information about the discussion can be found at:

http://www.ietf.org/mail-archive/web/sipping/current/msg15771.html

(Continue reading)

Jesske, R | 2 Jul 09:50 2008
Picon

Re: Progress on draft-jesske-sipping-etsi-ngn-reason-03

Hi Michael,
The location is used by some operators for O&M issues. Also for the Crank Back feature.
But with regard to the intworking for SIP we identified that the location gives no additional benefit.
Perhaps you realised that the Version -02 had the location included.

To complete Q.850: There is also a Diagnostics Field included which gives more information why the call was
released or a indication what to do. Like CCBS (Call Completion Busy Subscriber) is possible. 

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipping-bounces <at> ietf.org 
> [mailto:sipping-bounces <at> ietf.org] Im Auftrag von Michael Procter
> Gesendet: Dienstag, 1. Juli 2008 21:18
> An: sipping <at> ietf.org; Dale.Worley <at> comcast.net
> Betreff: Re: [Sipping] Progress on 
> draft-jesske-sipping-etsi-ngn-reason-03
> 
> Dale Worley wrote:
> > I assume that the ISUP reasons are two-digit codes, and there is no
> > intrinsic restriction on what two-digit combinations they can be.
> > That is, for REQ-1, codes 00 through 99 must be supported, even if
> > they have no assigned meaning now.
> 
> Not quite.  Q.850 cause values are 7 bits long, and (last 
> time I looked)
> approximately half of the 128 values have assigned meanings
> 
(Continue reading)


Gmane