Lab 1 / Task 8.X : AAR and SIP trunk issue (using "Redirecting Diversion Header Delivery - Outb

Hello,








It seems that it is not possible to place any AAR call from BR1 if you check "Redirecting Diversion Header Delivery - Outbound" box under BR1 SIP trunk configuration... (no information arrives to the BR1 gateway, according to "debug isdn q931" traces on R2 router).





Did anybody encounter this issue before ? How would it be possible to solve it (excepted by unchecking the box ;-) ?





This issue seems to be known in Michigan : http://www.mail-archive.com/[email protected]/msg13752.html .








Best regards,


SB.

Comments

  • Can you return the same information to us that Otto requested of the person on the OSL list?

    Please try the call again and do a "debug ccsip messages" and also a "debug voip dialpeer" on BR1 GW and paste the results here - all while the RDHD-O is checked for the SIP trunk on UCM.
    Then try the same exact call with the *only* difference being unchecking that RDHD-O field on the SIP trunk and send us that output.

    Cheers,

    Mark Snow, CCIE #14073
    Instructor
    Internetwork Expert, Inc.
    mailto:[email protected]
    http://blog.ine.com
    Toll Free: 877-224-8987
    Outside US: 775-826-4344



    On Dec 29, 2009, at 2:05 PM, sb.ccie wrote:

    Hello,


    It seems that it is not possible to place any AAR call from BR1 if you check "Redirecting Diversion Header Delivery - Outbound" box under BR1 SIP trunk configuration... (no information arrives to the BR1 gateway, according to "debug isdn q931" traces on R2 router).

    Did anybody had this issue before ? How would it be possible to solve it (excepted by unchecking the box ;-) ?

    This issue seems to be known in Michigan : http://www.mail-archive.com/[email protected]/msg13752.html .


    Best regards,
    SB.




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hi Mark,




    Thank you for your answer. And happy new year to INE's team and forum members ;-!





    I did issue a "debug voip dialpeer" too when I encountered this problem, but I hadn't any debug messages when the RDHD-O box was checked (and I had usual debug output when the box was unchecked).





    So, with the RDHD-O box checked in AAR conditions, it was like if the call never arrives to the BR1 SIP gateway.




    I will try again with "debug ccsip messages" at the end of the week and post my results here.

    How can I take a look at UCM traces concerning this specific case ?




    Best regards,




    SB.

  • Sounds good - waiting for the debugs!

    Just get us the "debug ccsip messages" from the router first, and we'll go from there if we need to get into CUCM traces.


    Cheers,


    On Jan 5, 2010, at 3:24 AM, sb.ccie wrote:

    Hi Mark,

    Thank you for your answer. And happy new year to INE's team and forum members ;-!

    I did issue a "debug voip dialpeer" too when I encountered this problem, but I hadn't any debug messages when the RDHD-O box was checked (and I had usual debug output when the box was unchecked).

    So, with the RDHD-O box checked in AAR conditions, it was like if the call never arrives to the BR1 SIP gateway.


    I will try again with "debug ccsip messages" at the end of the week and post my results here. How can I take a look at UCM traces concerning this specific case ? 


    Best regards, 
    SB.




    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hi Mark,



    The issue remains exactly the same. Here are the "debug ccsip messages" output. Is-it a CUCM bug ;-?

    NB 1 : This issue appears when calls are placed from HQ and BR2 towards BR1 in AAR conditions with RDHD-O box
    checked. See SIP debug output below.

    NB 2 : Without RDHD-O box checked in AAR conditions, everything is OK (I can provide the SIP debug output if needed).


    VORack08R2#
    VORack08R2#
    VORack08R2#no debug all
    All possible debugging has been turned off
    VORack08R2#debug ccsip messages
    SIP Call messages tracing is enabled
    VORack08R2#
    VORack08R2#
    VORack08R2#
    VORack08R2#
    Jan 17 10:48:42.105: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:[email protected]:5060 SIP/2.0
    Date: Mon, 18 Jan 2010 03:47:31 GMT
    Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649896
    Allow-Events: presence, kpml
    P-Asserted-Identity: "BR1 IP Phone" <sip:[email protected]>
    Supported: timer,resource-priority,replaces
    Min-SE: 1800
    Diversion: "HQ IP Phone" <sip:[email protected]>;reason=(null);privacy=off;screen=yes
    Remote-Party-ID: "BR1 IP Phone" <sip:[email protected]>;party=calling;screen=yes;privacy=off
    Content-Length: 209
    User-Agent: Cisco-CUCM7.0
    To: <sip:[email protected]>
    Contact: <sip:[email protected]:5060;transport=tcp>
    Expires: 180
    Content-Type: application/sdp
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK352e2e2d93
    CSeq: 101 INVITE
    Session-Expires: 1800
    Max-Forwards: 70

    v=0
    o=CiscoSystemsCCM-SIP 2000 1 IN IP4 177.1.10.20
    s=SIP Call
    c=IN IP4 177.2.11.1
    t=0 0
    m=audio 16648 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=ptime:20
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    Jan 17 10:48:42.113: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 400 Bad Request - 'Malformed CC-Diversion/Diversion/CC-Redirect Header'
    Reason: Q.850;cause=100
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649896
    Content-Length: 0
    To: <sip:[email protected]>;tag=1B8CAFC-18E6
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK352e2e2d93
    CSeq: 101 INVITE


    Jan 17 10:48:42.129: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    ACK sip:[email protected]:5060 SIP/2.0
    Date: Mon, 18 Jan 2010 03:47:31 GMT
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649896
    Allow-Events: presence, kpml
    Content-Length: 0
    To: <sip:[email protected]>;tag=1B8CAFC-18E6
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK352e2e2d93
    CSeq: 101 ACK
    Max-Forwards: 70


    VORack08R2#
    VORack08R2#
    VORack08R2#
    VORack08R2#
    Jan 17 10:49:06.505: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:[email protected]:5060 SIP/2.0
    Date: Mon, 18 Jan 2010 03:47:55 GMT
    Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649899
    Allow-Events: presence, kpml
    P-Asserted-Identity: "BR1 IP Phone" <sip:[email protected]>
    Supported: timer,resource-priority,replaces
    Min-SE: 1800
    Diversion: "BR2 IP Phone" <sip:[email protected]>;reason=(null);privacy=off;screen=yes
    Remote-Party-ID: "BR1 IP Phone" <sip:[email protected]>;party=calling;screen=yes;privacy=off
    Content-Length: 209
    User-Agent: Cisco-CUCM7.0
    To: <sip:[email protected]>
    Contact: <sip:[email protected]:5060;transport=tcp>
    Expires: 180
    Content-Type: application/sdp
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK364a3fdbd7
    CSeq: 101 INVITE
    Session-Expires: 1800
    Max-Forwards: 70

    v=0
    o=CiscoSystemsCCM-SIP 2000 1 IN IP4 177.1.10.20
    s=SIP Call
    c=IN IP4 177.2.11.1
    t=0 0
    m=audio 17634 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=ptime:20
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    Jan 17 10:49:06.513: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 400 Bad Request - 'Malformed CC-Diversion/Diversion/CC-Redirect Header'
    Reason: Q.850;cause=100
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649899
    Content-Length: 0
    To: <sip:[email protected]>;tag=1B92A4C-2055
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK364a3fdbd7
    CSeq: 101 INVITE


    Jan 17 10:49:06.529: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    ACK sip:[email protected]:5060 SIP/2.0
    Date: Mon, 18 Jan 2010 03:47:55 GMT
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649899
    Allow-Events: presence, kpml
    Content-Length: 0
    To: <sip:[email protected]>;tag=1B92A4C-2055
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK364a3fdbd7
    CSeq: 101 ACK
    Max-Forwards: 70


    VORack08R2#
    VORack08R2#
    VORack08R2#



    Best regards,
    SB.
  • Hello SB,

     

    It does look like it is a bug. The header being sent by CUCM contains an invalid character when the box is checked. Can you paste in the output as well without the box checked?

     

    Thanks!

  • Hi Josh,


    Thank you for your answer.

    Here is the debug output with RDHD-O box NOT checked (the call can be placed correctly). The debug output seems OK to me.


    VORack08R2#
    Jan 17 10:53:37.073: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:[email protected]:5060 SIP/2.0
    Date: Mon, 18 Jan 2010 03:52:26 GMT
    Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Allow-Events: presence, kpml
    P-Asserted-Identity: "BR1 IP Phone" <sip:[email protected]>
    Supported: timer,resource-priority,replaces
    Min-SE: 1800
    Remote-Party-ID: "BR1 IP Phone" <sip:[email protected]>;party=calling;screen=yes;privacy=off
    Content-Length: 209
    User-Agent: Cisco-CUCM7.0
    To: <sip:[email protected]>
    Contact: <sip:[email protected]:5060;transport=tcp>
    Expires: 180
    Content-Type: application/sdp
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK371462ed4
    CSeq: 101 INVITE
    Session-Expires: 1800
    Max-Forwards: 70

    v=0
    o=CiscoSystemsCCM-SIP 2000 1 IN IP4 177.1.10.20
    s=SIP Call
    c=IN IP4 177.2.11.1
    t=0 0
    m=audio 16736 RTP/AVP 0 101
    a=rtpmap:0 PCMU/8000
    a=ptime:20
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    Jan 17 10:53:37.093: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Date: Sun, 17 Jan 2010 10:53:37 GMT
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Allow-Events: kpml, telephone-event
    Content-Length: 0
    To: <sip:[email protected]>
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK371462ed4
    CSeq: 101 INVITE
    Server: Cisco-SIPGateway/IOS-12.x


    Jan 17 10:53:37.229: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 183 Session Progress
    Date: Sun, 17 Jan 2010 10:53:37 GMT
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Allow-Events: kpml, telephone-event
    Supported: sdp-anat
    Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
    Content-Length: 244
    To: <sip:[email protected]>;tag=1BD4BBC-25F1
    Contact: <sip:[email protected]:5060;transport=tcp>
    Content-Disposition: session;handling=required
    Content-Type: application/sdp
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK371462ed4
    CSeq: 101 INVITE
    Server: Cisco-SIPGateway/IOS-12.x

    v=0
    o=CiscoSystemsSIP-GW-UserAgent 4130 6236 IN IP4 177.1.254.2
    s=SIP Call
    c=IN IP4 177.1.254.2
    t=0 0
    m=audio 16658 RTP/AVP 0 101
    c=IN IP4 177.1.254.2
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20

    Jan 17 10:53:37.249: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    SUBSCRIBE sip:[email protected]:5060;transport=tcp SIP/2.0
    Date: Mon, 18 Jan 2010 03:52:26 GMT
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    P-Asserted-Identity: "BR1 IP Phone" <sip:[email protected]>
    Event: kpml
    Content-Length: 370
    User-Agent: Cisco-CUCM7.0
    To: <sip:[email protected]>;tag=1BD4BBC-25F1
    Contact: <sip:177.1.10.20:5060;transport=tcp>
    Expires: 7200
    Content-Type: application/kpml-request+xml
    Call-ID: [email protected]
    Accept: application/kpml-response+xml
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK3875a58db5
    CSeq: 102 SUBSCRIBE
    Max-Forwards: 70

    <?xml version="1.0" encoding="UTF-8" ?>
    <kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">

    <pattern interdigittimer="7260000" persist="persist">
    <regex tag="dtmf">[x*#ABCD]</regex>
    </pattern>

    </kpml-request>


    Jan 17 10:53:37.261: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 200 OK
    Date: Sun, 17 Jan 2010 10:53:37 GMT
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Content-Length: 0
    To: <sip:[email protected]>;tag=1BD4BBC-25F1
    Contact: <sip:[email protected]:5060;transport=tcp>
    Expires: 7200
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK3875a58db5
    CSeq: 102 SUBSCRIBE


    Jan 17 10:53:37.297: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    NOTIFY sip:177.1.10.20:5060;transport=tcp SIP/2.0
    Date: Sun, 17 Jan 2010 10:53:37 GMT
    From: <sip:[email protected]>;tag=1BD4BBC-25F1
    Event: kpml
    Content-Length: 0
    User-Agent: Cisco-SIPGateway/IOS-12.x
    To: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Contact: <sip:[email protected]:5060;transport=tcp>
    Call-ID: [email protected]
    Subscription-State: active
    Via: SIP/2.0/TCP 177.1.254.2:5060;branch=z9hG4bK471A89
    CSeq: 101 NOTIFY
    Max-Forwards: 70


    Jan 17 10:53:37.309: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 200 OK
    Date: Mon, 18 Jan 2010 03:52:26 GMT
    From: <sip:[email protected]>;tag=1BD4BBC-25F1
    Content-Length: 0
    To: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.254.2:5060;branch=z9hG4bK471A89
    CSeq: 101 NOTIFY


    Jan 17 10:53:40.557: %ISDN-6-CONNECT: Interface Serial0/0/0:2 is now connected to 17752011001 N/A
    Jan 17 10:53:40.557: %ISDN-6-CONNECT: Interface Serial0/0/0:2 is now connected to 17752011001 N/A
    Jan 17 10:53:40.569: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 200 OK
    Date: Sun, 17 Jan 2010 10:53:37 GMT
    Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Allow-Events: kpml, telephone-event
    Supported: replaces
    Supported: sdp-anat
    Remote-Party-ID: <sip:[email protected]>;party=called;screen=no;privacy=off
    Content-Length: 244
    Require: timer
    To: <sip:[email protected]>;tag=1BD4BBC-25F1
    Contact: <sip:[email protected]:5060;transport=tcp>
    Content-Disposition: session;handling=required
    Content-Type: application/sdp
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK371462ed4
    CSeq: 101 INVITE
    Server: Cisco-SIPGateway/IOS-12.x
    Session-Expires: 1800;refresher=uac

    v=0
    o=CiscoSystemsSIP-GW-UserAgent 4130 6236 IN IP4 177.1.254.2
    s=SIP Call
    c=IN IP4 177.1.254.2
    t=0 0
    m=audio 16658 RTP/AVP 0 101
    c=IN IP4 177.1.254.2
    a=rtpmap:0 PCMU/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20

    Jan 17 10:53:40.593: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    ACK sip:[email protected]:5060;transport=tcp SIP/2.0
    Date: Mon, 18 Jan 2010 03:52:26 GMT
    From: "BR1 IP Phone" <sip:[email protected]>;tag=06bb5c4b-f416-48f6-9225-822962b6cef1-38649902
    Allow-Events: presence, kpml
    Content-Length: 0
    To: <sip:[email protected]>;tag=1BD4BBC-25F1
    Call-ID: [email protected]
    Via: SIP/2.0/TCP 177.1.10.20:5060;branch=z9hG4bK3967dac7f
    CSeq: 101 ACK
    Max-Forwards: 70


    VORack08R2#



    Best regards,
    SB.
  • Hey SB,

     

    Thanks for the output. It does appear that the gateway simply does not believe the diversion header is properly formatted, however it should be ok, which more than likely confirms a bug with either CUCM 7.0 or the IOS.

     

    As you can see the header here, it appears that it would be fine, since it is very similar to the Invite header

    Diversion: "HQ IP Phone" <sip:[email protected]>;reason=(null);privacy=off;screen=yes

    One thing you can try is to change the HQ IP Phone name to simply hqipphone and see if this works. Apparently some versions of code have had issues with spaces and commas
    in the device name.

    Let us know.

  •  

     

     


    It seems it is a bug in CUCM.


    Reason is set to (null) in the diversion header.


    Diversion: "BR2 IP Phone" <sip:[email protected]>;reason=(null);privacy=off;screen=yes


     

    It is not a valid reason, and that is why gateway returns Malformed Diversion Header  message.


    There is a related Cisco bug


    CSCta13488 : SIP Diversion Header reason is null


    There is no workaround for this bug. It was fixed in 7.0(2.22030.1).


    Does someone know what version of CUCM is currently in the lab?

    Alex

  • If “Redirecting Diversion Header Delivery – Outbound” must be checked on the SIP trunk, the workaround is to uncheck “Retain this destination in the call forwarding history” in the AAR settings of the called number. If this box is unchecked the diversion header is not generated.

  • BTW, I have found that the same BUG is activated for the MVA calls, when the call is going out through the SIP gateway.

Sign In or Register to comment.