Re: Dialoge states / Interworking CCBS/CCNR

Hello Mark,

Some issues inline 

 I am still confused about how dialog state can be used to implement CCBS-like service when the called party
is a normal SIP UA (rather than a PSTN gateway).

If there are three dialogs in progress at the terminating UA, how do you know which one is keeping the user
'busy'. Perhaps two of them are for IM sessions, and the user is happy to take voice calls whilst the IM
sessions are ongoing. 

What about the remote/local-session-description (not always available)?

Or there are might be some user preferences like "urgent"/"busy" that could be assigned to a dialog by the user.

In general I share your confusion and would like to ask the group for clarification on this topic.  

Or is your intention only to implement an 'asymetric' service, where SIP users can invoke CCBS against PSTN
endpoints but not vice-versa ? 

That's the main target, but even in this case we are missing the general consensus about the definition of a
dialog busyness from the user perspective.

comments? 

_______________________________________________
Sipping mailing list  https://www1.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

Re: Dialoge states / Interworking CCBS/CCNR

Denis,

It would seem that, if one really feels the need to do this at all (given 
that voice-mail tends to obviate a busy condition), that it should be 
interworked with a presence interworking application, as this is 
essentially a subscription to the presence of the destination user.

Mike

At 10:55 AM 8/1/2002 +0200, Alexeitsev, D wrote:
>Hello Mark,
>
>Some issues inline
>
>  I am still confused about how dialog state can be used to implement 
> CCBS-like service when the called party is a normal SIP UA (rather than a 
> PSTN gateway).
>
>If there are three dialogs in progress at the terminating UA, how do you 
>know which one is keeping the user 'busy'. Perhaps two of them are for IM 
>sessions, and the user is happy to take voice calls whilst the IM sessions 
>are ongoing.
>
>What about the remote/local-session-description (not always available)?
>
>Or there are might be some user preferences like "urgent"/"busy" that 
>could be assigned to a dialog by the user.
>
>In general I share your confusion and would like to ask the group for 
>clarification on this topic.

RE: Dialoge states / Interworking CCBS/CCNR

Picking up on a couple of comments made in this thread:

I don't think voice mail completely replaces the traditional CCBS in public
or private PSTN/ISDN. With voice mail the onus is on the recipient to return
the call (or take whatever action is requested). The recipient will do so at
a time that suits him. Often this is good enough for the caller, but not
always. Sometimes he will regard the situation as urgent enough to make the
call as soon as the called user becomes "free". For this traditional
networks offer both CCBS and call waiting. Call waiting means that the
caller has to keep the call open and keep listening, which may or may not
suit the caller. CCBS gives an intermediate capability. It all comes down to
what the caller prefers in a given situation.

I would not be happy about just addressing Denis's "main target", where SIP
users can invoke a CCBS-like service on PSTN/ISDN users. The other
direction, and also the provision of a similar service between SIP users,
are equally important. If a similar service between SIP users can already be
made available through use of presence, then we should see whether this can
be interworked with PSTN/ISDN (including QSIG as well as ISUP) in each
direction.

--------------------------------------------------------------
John Elwell (john.elwell <at> siemens.com)
Siemens Communications Limited,
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

Re: Dialoge states / Interworking CCBS/CCNR

Hello John

Thanks for the constructive comments!

Some issues inline:

I would not be happy about just addressing Denis's "main target", where SIP
users can invoke a CCBS-like service on PSTN/ISDN users. The other
direction, and also the provision of a similar service between SIP users,
are equally important. If a similar service between SIP users can already be
made available through use of presence, then we should see whether this can
be interworked with PSTN/ISDN (including QSIG as well as ISUP) in each
direction.

[DA] Sorry for confusion cased by the "main target" phrase. What we are trying to achieve is to get the
service through the GW in both directions. The targeting comes from the issue that there is no common
understanding when the UAs user is busy. That gave us a thought to start first with the SIP->ISDN
direction. 
You are correct speaking about the SIP-SIP case as well. It wont be beneficial to separate this cases. That
is why we will base our research on the event package for dialog state as it is the basic element for this type
of services in the SIP net.

I'm not sure I fully understand how the presence information can help in the determination of the user
busyness. 
Would it be possible to solve this issue by extending the notion of the virtual FSM to represent the state of
the User?

Greetings,
Denis Alexeitsev

RE: Dialoge states / Interworking CCBS/CCNR

John,

My comment concerning voice-mail was directed to the fact that a call 
forwarded to voice mail is never busy.  Do current implementations of CCBS 
get triggered off of Call Forward Busy?

My thought in terms of presence-CCBS IW was that a request from the PSTN 
for CCBS would trigger a Subscription to the SIP user's presence.  (I won't 
re-trace the discussion about Open/Close versus more detailed 
states.)  Upon Notification of the "open for voice communication" state 
(however that is rendered), the IW GW would send the appropriate CCBS 
signaling that triggers the PSTN user to re-attempt the voice call.

In the opposite direction, if the SIP user submits a Subscription for 
presence related to voice communication state of the PSTN user, then 
corresponding CCBS procedures are invoked.  When CCBS indicates PSTN user 
is not busy, then Notification to SIP user indicates "open for voice 
communication."

That is the overall conecpt, but the details still fuzzy.

Mike

At 04:13 PM 8/1/2002 +0100, Elwell, John wrote:
>Picking up on a couple of comments made in this thread:
>
>I don't think voice mail completely replaces the traditional CCBS in public
>or private PSTN/ISDN. With voice mail the onus is on the recipient to return
>the call (or take whatever action is requested). The recipient will do so at
>a time that suits him. Often this is good enough for the caller, but not

Comments on Overlap Security Considerations

Re: Comments on Overlap Security Considerations

Mike,

How would the terminating GW determine if the INVITE originated in the 
IP world or the PSTN world?

thanks,
-rohan

On Thursday, August 1, 2002, at 09:22 AM, Mpierce1 <at> aol.com wrote:

> To all,
>
> I find the new security considerations section in the recent 
> draft-ietf-sipping-overlap-02 to be confusing and inadequate. While the 
> draft addresses the case of interworking PSTN-SIP-PSTN, this new 
> Security Considerations section seems to be addressing the case of 
> calls originated by a SIP telephone. (Yes, I know, you're trying to 
> define a signaling which is oblivious to whether it came from an 
> individual user's telephone-type device or from a service provider's 
> gateway, but I don't believe security can be done one way to suit both 
> architectures.)
>
> Having the egress GW initiate an authentication procedure (multiple 
> messages?) for each INVITE received with an incomplete address may 
> prevent an attacker from tying up "all" available ports out of that GW 
> into the PSTN, but it introduces another problem - Denial of Service 
> because of the overload of processing the authentications. Anyway, what 
> limit would be applied by the GW, considering that the described 
> procedues allow multiple ports to be temporarily occupied for one call 
> in the normal case? In addition, "authentication" would not help, since 
> the originating GW will always be found to be "authentic". Would this 
> procedure then limit the number of simultaneous overlap calls from one 
> ingress GW? It is unknown what "similar calls" means that would be 
> rejected.
>
> The case being addressed seems to be one in which the attack is 
> originatated from within the IP domain. A partial solution is to not 
> allow overlap to originate there. In any case, this attack is unrelated 
> to overlap. A user in the IP domain could initiate multiple normal 
> (en-bloc) calls and do the same thing. If a solution is needed to 
> prevent an attacker in the IP domain from attempting this type of 
> attack, it needs to be defined someplace else for all cases, not just 
> overlap.
>
> The only case of overlap (INVITEs with an incomplete number) should be 
> for a call which originates in the PSTN and interworks to IP through a 
> GW (and may go back to the PSTN). Then, an attacker (in the PSTN) would 
> have to tie up many resources at the originating side in order to 
> attempt what is described in the Security Considerations. It is the 
> responsiblity of the originating PSTN to deal with this problem.
>
> The only responsibility of the egress GW is to ensure that an attempt 
> to use overlap came from another GW. Whether this is based on a 
> previously established trust relationship or real-time authentication 
> is not important. However, no limit on the number of simultaneous calls 
> can be applied.
>
> Mike Pierce
> Artel
>

RE: Dialoge states / Interworking CCBS/CCNR

Mike,

See in-line.

John

--------------------------------------------------------------
John Elwell (john.elwell <at> siemens.com)
Siemens Communications Limited,
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer <at> cisco.com]
> Sent: 01 August 2002 17:11
> To: Elwell, John
> Cc: Alexeitsev, D; mwatson <at> nortelnetworks.com; 
> sipping <at> ietf.org; Poetzl,
> Joachim
> Subject: RE: [Sipping] Dialoge states / Interworking CCBS/CCNR
> 
> 
> John,
> 
> My comment concerning voice-mail was directed to the fact that a call 
> forwarded to voice mail is never busy.  Do current 
> implementations of CCBS 
> get triggered off of Call Forward Busy?

[JRE] In most cases probably not, except where used in conjunction with a
forwarding override capability (more common on PBXs than public networks),
thereby forcing the call to encounter busy or call waiting. In theory, of
course, an entity could invoke CCBS (or CCNR) at any time, not necessarily
after encountering busy / call waiting.

> 
> My thought in terms of presence-CCBS IW was that a request 
> from the PSTN 
> for CCBS would trigger a Subscription to the SIP user's 
> presence.  (I won't 
> re-trace the discussion about Open/Close versus more detailed 
> states.)  Upon Notification of the "open for voice 
> communication" state 
> (however that is rendered), the IW GW would send the appropriate CCBS 
> signaling that triggers the PSTN user to re-attempt the voice call.
> 
> In the opposite direction, if the SIP user submits a Subscription for 
> presence related to voice communication state of the PSTN user, then 
> corresponding CCBS procedures are invoked.  When CCBS 
> indicates PSTN user 
> is not busy, then Notification to SIP user indicates "open for voice 
> communication."
> 
> That is the overall conecpt, but the details still fuzzy.

[JRE] Yes, that is the sort of thing I imagined.

> 
> Mike
> 
> 
> At 04:13 PM 8/1/2002 +0100, Elwell, John wrote:
> >Picking up on a couple of comments made in this thread:
> >
> >I don't think voice mail completely replaces the traditional 
> CCBS in public
> >or private PSTN/ISDN. With voice mail the onus is on the 
> recipient to return
> >the call (or take whatever action is requested). The 
> recipient will do so at
> >a time that suits him. Often this is good enough for the 
> caller, but not
> >always. Sometimes he will regard the situation as urgent 
> enough to make the
> >call as soon as the called user becomes "free". For this traditional
> >networks offer both CCBS and call waiting. Call waiting 
> means that the
> >caller has to keep the call open and keep listening, which 
> may or may not
> >suit the caller. CCBS gives an intermediate capability. It 
> all comes down to
> >what the caller prefers in a given situation.
> >
> >I would not be happy about just addressing Denis's "main 
> target", where SIP
> >users can invoke a CCBS-like service on PSTN/ISDN users. The other
> >direction, and also the provision of a similar service 
> between SIP users,
> >are equally important. If a similar service between SIP 
> users can already be
> >made available through use of presence, then we should see 
> whether this can
> >be interworked with PSTN/ISDN (including QSIG as well as 
> ISUP) in each
> >direction.
> >
> >--------------------------------------------------------------
> >John Elwell (john.elwell <at> siemens.com)
> >Siemens Communications Limited,
> >--------------------------------------------------------------
> >         Internet communications are not secure and therefore Siemens
> >Communications Limited does not accept legal responsibility for the
> >contents of this message. Any views or opinions presented are solely
> >those of the author and do not necessarily represent those of Siemens
> >Communications Limited unless otherwise specifically stated.
> >
> >
> > > -----Original Message-----
> > > From: Michael Hammer [mailto:mhammer <at> cisco.com]
> > > Sent: 01 August 2002 15:03
> > > To: Alexeitsev, D
> > > Cc: mwatson <at> nortelnetworks.com; sipping <at> ietf.org; Poetzl, Joachim
> > > Subject: Re: [Sipping] Dialoge states / Interworking CCBS/CCNR
> > >
> > >
> > > Denis,
> > >
> > > It would seem that, if one really feels the need to do this
> > > at all (given
> > > that voice-mail tends to obviate a busy condition), that 
> it should be
> > > interworked with a presence interworking application, as this is
> > > essentially a subscription to the presence of the 
> destination user.
> > >
> > > Mike
> > >
> > >
> > > At 10:55 AM 8/1/2002 +0200, Alexeitsev, D wrote:
> > > >Hello Mark,
> > > >
> > > >Some issues inline
> > > >
> > > >  I am still confused about how dialog state can be used to
> > > implement
> > > > CCBS-like service when the called party is a normal SIP UA
> > > (rather than a
> > > > PSTN gateway).
> > > >
> > > >If there are three dialogs in progress at the terminating
> > > UA, how do you
> > > >know which one is keeping the user 'busy'. Perhaps two of
> > > them are for IM
> > > >sessions, and the user is happy to take voice calls whilst
> > > the IM sessions
> > > >are ongoing.
> > > >
> > > >What about the remote/local-session-description (not always
> > > available)?
> > > >
> > > >Or there are might be some user preferences like
> > > "urgent"/"busy" that
> > > >could be assigned to a dialog by the user.
> > > >
> > > >In general I share your confusion and would like to ask the
> > > group for
> > > >clarification on this topic.
> > > >
> > > >Or is your intention only to implement an 'asymetric'
> > > service, where SIP
> > > >users can invoke CCBS against PSTN endpoints but not vice-versa ?
> > > >
> > > >That's the main target, but even in this case we are missing
> > > the general
> > > >consensus about the definition of a dialog busyness from the
> > > user perspective.
> > > >
> > > >comments?
> > > >
> > > >
> > > >_______________________________________________
> > > >Sipping mailing list  
> https://www1.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
> > >
> > >
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.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
> > >
> 

_______________________________________________
Sipping mailing list  https://www1.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

Question about SIP support for real-time fax

Dear all,

I resubmit this question since it has got no answer yet.

A about draft-ietf-sipping-realtimefax-00.txt,

In section 5.1 "Internet fax device  fax only support" call sequence, it
shows a diagram to establish T.38/UDPTL session from the beginning. We tried
this scenario and realized the following thing:

--
(1) In case both SIP-UA are telephony gateway which are configured to
support fax only, T.38/UDPTL session are established as the section 5.1
represents.

(2) FAX machines tries to negotiate their capability by exchanging CNG and
CED tones.

(3) As T.38/UDPTL session basically doesn't have a capability to pass
through CNG or CED tones, this negotiation fails.

(4) The Calling FAX machine terminate fax call as it cannot get CED response
from the callee side. Then, FAX fails.

---

So, if FAX machines need CNG/CED exchange to start fax, this call scenario
is not appropriate. Instead, we should always use section 5.2 call scenario,
which use voice stream to exchange CNG/CED first.

So, my questions is that, is section 5.1 is appropriate from fax machines'
and T.38 session's perspective?

If not, I would like to recommend to remover section 5.1 of
draft-ietf-sipping-realtimefax-00.txt, and allows only the procedure
described in section 5.2.

Regards,
- Eiji Tomimura

--

-- 
Eiji Tomimura 
Senior Engineer 
Systems Technology Dept., Information Technology R&D Laboratories
Sumitomo Electric Industries, Ltd.
Phone: +81-6-6466-5609  Fax: +81-6-6466-5732  Email: tomimura <at> sei.co.jp

_______________________________________________
Sipping mailing list  https://www1.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

Re: Question about SIP support for real-time fax

Hi  Eiji,

If i may attempt to respond, i think what you've actually tried out is the
scenario in section 5.2
where a voice path has to exist for receiving end to detect the fax tones
and then setup a SIP connection. See section D.2.2.4 of T.38(04/02).

However section 5.1 refers to a case where a voice path does not exist
(only fax) and negotiation  is done by passing relevant information in the
SIP SDP. And therefore, there is no need to allow voice path first for
tones to pass and then detect fax.
(In fact negotiation in both cases is actually done using SIP SDP)

Please see  section D.2.1.1 and D.2.2.3 of ITU T.38 specs(04/02).

Scenario in Section 5.1 does appear to be a valid scenario from T.38
perspective.

Section 4 of the referenced draft says:
"The Internet telephony gateway only supports T.38 real-time
   fax communications (by design or by configuration).  In this case,
   the Internet fax gateway SHOULD initiate the SIP session with T.38
   SDP capabilities (this is typically the case of Internet fax
   terminals, also called Internet-aware fax devices or the case of
   gateways statically configured to support T.38 fax calls only)".

regards
Harsh Bhondwe
hughes software systems

Eiji Tomimura <tomimura <at> sei.co.jp> on 08/02/2002 01:31:37 PM

To:   sipping <at> ietf.org
cc:

Subject:  [Sipping] Question about SIP support for real-time fax

Dear all,

I resubmit this question since it has got no answer yet.

A about draft-ietf-sipping-realtimefax-00.txt,

In section 5.1 "Internet fax device  fax only support" call sequence, it
shows a diagram to establish T.38/UDPTL session from the beginning. We
tried
this scenario and realized the following thing:

--
(1) In case both SIP-UA are telephony gateway which are configured to
support fax only, T.38/UDPTL session are established as the section 5.1
represents.

(2) FAX machines tries to negotiate their capability by exchanging CNG and
CED tones.

(3) As T.38/UDPTL session basically doesn't have a capability to pass
through CNG or CED tones, this negotiation fails.

(4) The Calling FAX machine terminate fax call as it cannot get CED
response
from the callee side. Then, FAX fails.

---

So, if FAX machines need CNG/CED exchange to start fax, this call scenario
is not appropriate. Instead, we should always use section 5.2 call
scenario,
which use voice stream to exchange CNG/CED first.

So, my questions is that, is section 5.1 is appropriate from fax machines'
and T.38 session's perspective?

If not, I would like to recommend to remover section 5.1 of
draft-ietf-sipping-realtimefax-00.txt, and allows only the procedure
described in section 5.2.

Regards,
- Eiji Tomimura

--
Eiji Tomimura
Senior Engineer
Systems Technology Dept., Information Technology R&D Laboratories
Sumitomo Electric Industries, Ltd.
Phone: +81-6-6466-5609  Fax: +81-6-6466-5732  Email: tomimura <at> sei.co.jp

_______________________________________________
Sipping mailing list  https://www1.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

_______________________________________________
Sipping mailing list  https://www1.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