Subject: Re: [Sipping] Comments on draft-zhang-sipping-overlap-00.txt

From: "zhangps" <[email-masked]>
Date: Wed, 2 Nov 2005 10:51:57 +0800

Dear Gonzalo and Ramesh:

 First i answer Mr Gonazlo's question.Mr Gonazlo said that when using INFO solving the SIP Overlap needs the UAS  additional function:he must know that is a overlap method, then sending a 183 without message body and waiting the addditional  digits.

 AS Gonzalo said, we strongly suggest using SIP Enbloc in the first choice.So the overlap of SIP Overlap only be used in  special envionment.In our suggestions we dividing the there elements:Originating Server、Intermediate Server、Terminating Server,they know what is 

his duty.Just using Invite method solving sip overlap,the receiver also must know that is a overlap and release the first Invite when receiving the second Invite message,that is also need the receiver's addition function.

We think using INFO can easily be managed contrast with  INVITE as we write in the draft.

Importantly, we can disscuss whether it has many serious problems when using INFO method.

Now answer Mr Ramesh's question:

  Ramesh said when receiving 183,the calling SIP-ISUP interworking unit (just as our Originating Server）must map it to CPG. We think if we do so simply,it will  bring on   many problems.As we know,the SIP Terminal is a trustless entity in the network,if it sends malicious  attacking,for example sending many 180 or 183 messages,how does the calling SIP-ISUP Interworking unit do? If it maps,it will be horrible and the PSTN network maybe overload.

  So in this problem,we have two opinions:

   firt, the calling SIP-ISUP interworking unit must judge whether need map the message.for example,if the 183 message has no message 

body,it will not mapp it to ISUP message,because there has no meaning if the 183 without special parameter(as suggesting by ITU）.But if there is a message body in 183,the calling SIP-ISUP interworking unit must mapping,becasue it need to establish the back tone path.

   Second,we think the calling SIP-ISUP interworking unit must have a range to deal with the mutiple 18* messages.

  In our suggestions,the Proxy may be in Originating Server or Intermediate Server,but it must not be Terminating Server.So when the Proxy receiving INVITE message and can not route,it will send 484 message.This action has referded in draft. 

But in the Terminating Server, it must end the SIP overlap and send the request to the next hop,the request maybe overlap/enbloc ISUP message or enbloc SIP message including complete called party number.

Best Regards

   Zhang  peng sheng  
China Telecom-Guangzhou Research and Development Center
Guangzhou Telecom Academy of Science & Technology
Network Technology Research Dept.
 
Add：109 Zhougshan Ave,Tianhe District,Guangzhou,P.R.C
Postcode:510630 
Mobile:+86-139-260-98-260
Tel:+86- 20- 38639313
Fax:+86- 20- 38639326
  ----- Original Message ----- 
  From: Ramesh 
  To: Gonzalo Camarillo 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; sipping 
  Sent: Wednesday, November 02, 2005 1:09 AM
  Subject: Re: [Sipping] Comments on draft-zhang-sipping-overlap-00.txt

  Hi all,
      There is another issue when Interoping with ISUP and using 183 message. We can send 183, which is translated to CPG in SS7, only after we get to the ACM state. SAM is before ACM and So sending INFO after 183 is not possiblity in case of SAM. We need to only use INVITE to send the additional digits.
     This brings about another issue with SAM. If the proxy is the router of the message How will the proxy know to wait for the a complete set of digits without looking at the payload? Is there any field in the INVITE that states that there are additional digits coming in the subsequent invites.
    Please let us know if we are wrong in our procedure here.

  Thanks
  Ramesh & phanidra 

  On 10/30/05, Gonzalo Camarillo <[email-masked]> wrote: 
    Hi,

    some comments on the following draft:

    http://www.ietf.org/internet-drafts/draft-zhang-sipping-overlap-00.txt

    First paragraph of the introduction:

    "There are two approaches of sending overlap signalling in a SIP
        network described in RFC 3578 [2]: sending the subsequent digits in a 
        SIP request (e.g., INFO [3]) within an early dialog, or sending a new
        INVITE which contains all the digits received so far every time a new
        SAM is received.  RFC 3578 mainly focuses on the INVITE method and 
        doesn`t address the INFO method in detail."

    This paragraph in misleading. RFC 3578 states that the INFO approach has
    a number of problems, and thus, it is not recommended.

    Regarding the INFO-based solution that was proposed a very long time ago 
    and you are proposing again in this draft, has the disadvantage that
    does not work with regular UASs. That is, the receiver of the INVITE
    needs to understand the INFOs that follow it. If you are thinking of an
    environment where all you do is trunking between gateways and where you
    will never figure out that a service had to be applied, and was not,
    when you receive further digits, this approach could work. In a more
    general enviornment, it has serious problems. 

    Therefore, I would only recommend using the INFO-based approach in
    environments with the characteristics I have mentioned before.

    Cheers,

    Gonzalo

    _______________________________________________ 
    Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
    This list is for NEW development of the application of SIP
    Use [email-masked] for questions on current sip
    Use [email-masked] for new developments of core SIP

  -- 
  cheers
  ramesh 

    Zhang peng sheng  
China Telecom-Guangzhou Research and Development Center
Guangzhou Telecom Academy of Science & Technology
Network Technology Research Dept.
 
Add：109 Zhougshan Ave,Tianhe District,Guangzhou,P.R.C
Postcode:510630 
Mobile:139-260-98-260
Tel:+86 20 38639313
Fax:+86 20 38639326

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Ramesh <[email-masked]>
Date: Wed, 2 Nov 2005 09:13:43 -0700

Further questions inline.

On 11/1/05, zhangps <[email-masked]> wrote:
>
>  Dear Gonzalo and Ramesh:
>    First i answer Mr Gonazlo's question.Mr Gonazlo said that when using
> INFO solving the SIP Overlap needs the UAS additional function:he must
> know that is a overlap method, then sending a 183 without message body and
> waiting the addditional digits.
>   AS Gonzalo said, we strongly suggest using SIP Enbloc in the first
> choice.So the overlap of SIP Overlap only be used in special envionment.Inour suggestions we dividing the there elements:Originating
> Server、Intermediate Server、Terminating Server,they know what is
>  his duty.Just using Invite method solving sip overlap,the receiver also
> must know that is a overlap and release the first Invite when receiving
> the second Invite message,that is also need the receiver's addition
> function.
>   Ramesh said when receiving 183,the calling SIP-ISUP interworking unit
> (just as our Originating Server）must map it to CPG. We think if we do so
> simply,it will bring on many problems.As we know,the SIP Terminal is a
> trustless entity in the network,if it sends malicious attacking,for example
> sending many 180 or 183 messages,how does the calling SIP-ISUP Interworking
> unit do? If it maps,it will be horrible and the PSTN network maybe
> overload.
>

So in this problem,we have two opinions:
>   firt, the calling SIP-ISUP interworking unit must judge whether need map
> the message.for example,if the 183 message has no message
>  body,it will not mapp it to ISUP message,because there has no meaning if
> the 183 without special parameter(as suggesting by ITU）.But if there is a message
> body in 183,the calling SIP-ISUP interworking unit must mapping,becasue it
> need to establish the back tone path.
>

My contention is that we will not get to the 183 call state until the call
gets Routed. Being a b2bua that support SIP-T we should attempt routing the
call until we have all the digits to route, which we will know by looking up
end of pulsing in the ISUPbody, or minimum routable digits. Moreover B2Bua
cannot send an 183 back to the callee as it does not have a meaningful body
to attach to the 183 message. This is the reasoning behind my statement.

Second,we think the calling SIP-ISUP interworking unit must have a range to
> deal with the mutiple 18* messages.
>    In our suggestions,the Proxy may be in Originating Server or
> Intermediate Server,but it must not be Terminating Server.So when the
> Proxy receiving INVITE message and can not route,it will send 484
> message.This action has referded in draft.
>

But in the Terminating Server, it must end the SIP overlap and send the
> request to the next hop,the request maybe overlap/enbloc ISUP message or
> enbloc SIP message including complete called party number
>

Please explain this further .

Best Regards
>  *From:* Ramesh <[email-masked]>
>  *To:* Gonzalo Camarillo <[email-masked]>
>  *Cc:* [email-masked] ; [email-masked] ;
> [email-masked] ; [email-masked] ; [email-masked] ;
> [email-masked] ; sipping <[email-masked]>
>  *Sent:* Wednesday, November 02, 2005 1:09 AM
>  *Subject:* Re: [Sipping] Comments on draft-zhang-sipping-overlap-00.txt
>
> Hi all,
> There is another issue when Interoping with ISUP and using 183 message. We
> can send 183, which is translated to CPG in SS7, only after we get to the
> ACM state. SAM is before ACM and So sending INFO after 183 is not possiblity
> in case of SAM. We need to only use INVITE to send the additional digits.
> This brings about another issue with SAM. If the proxy is the router of
> the message How will the proxy know to wait for the a complete set of digits
> without looking at the payload? Is there any field in the INVITE that states
> that there are additional digits coming in the subsequent invites.