[Serusers] 400 Bad Request from SUBSCRIBE messages

[Daniel-Constantin Mierla]

The PA module from 0.8.14 is totally different (it is mainly the one 
from 0.8.12) than the one of unstable branch. The unstable version has a 
lot of improvements developed by Jamey Hicks.

Daniel

On 9/9/2004 9:01 AM, blanca_mayayo at lycos.es wrote:

>  
>
> Hi,
>
>  
>
>  
>
> I have a problem with the 0.8.14 version from SER, that didn't happen 
> in the unstable version 0.8.13 from cvs. The configuration scripts in 
> both machines are identical, however, in the latest version I always 
> obtain the response '400 Bad Request' from the SUBSCRIBE messages. 
> Here is the piece of code corresponding to SUBSCRIBE treatment:
>
>  
>
>  
>
>  
>
> if (uri==myself) {
>
>                 if (method=="REGISTER") {
> # Uncomment this if you want to use digest authentication
>                         if (!www_authorize("cdshuesca.es", 
> "subscriber")) {
>                                 www_challenge("cdshuesca.es", "0");
>                                 break;
>
>                         };
>                         save("location");
>                         log(1,"REGISTER recibido\n");
>                         break;
>                 };
>
>                 if (method=="SUBSCRIBE") {
>                 #create new transaction state
>                         log(1,"SUBSCRIBE received\n");
>                         if (t_newtran()) {
>                         handle_subscription("registrar");
>                         log(1,"end of SUBCRIBE treatment\n");
>         &nbs p;               break;
>                         }
>
>                 };
>
>  
>
> Here I include the corresponding part of the debugging messages that 
> SER provides:
>
>  
>
> 7(987) SIP Request:
>
>  7(987)  method:  <SUBSCRIBE>
>
>  7(987)  uri:     <sip:blanch at cdshuesca.es:5060;transport=udp>
>
>  7(987)  version: <SIP/2.0>
>
>  7(987) parse_headers: flags=1
>
>  7(987) get_hdr_field: cseq <CSeq>: <1> <SUBSCRIBE>
>
>  7(987) end of header reached, state=9
>
>  7(987) DEBUG: get_hdr_field: <To> [28]; uri=[blanch at cdshuesca.es:5060]
>
>  7(987) DEBUG: to body [<blanch at cdshuesca.es:5060>
>
> ]
>
>  7(987) Found param type 232, <branch> = 
> <z9hG4bK8bc874a7fea4f4ea7042531e9af21d8d>; state=16
>
>  7(987) end of header reached, state=5
>
>  7(987) parse_headers: Via found, flags=1
>
>  7(987) parse_headers: this is the first via
>
>  7(987) After parse_msg...
>
>  7(987) preparing to run routing scripts...
>
>  7(987) DEBUG : is_maxfwd_present: searching for max_forwards header
>
>  7(987) parse_headers: flags=128
>
>  7(987) DEBUG: is_maxfwd_present: value = 70
>
>  7(987) DEBUG: add_param: tag=4407
>
>  7(987) end of header reached, state=29
>
>  7(987) parse_headers: flags=256
>
>  7(987) DEBUG: get_hdr_body : content_length=0
>
>  7(987) found end of header
>
>  7(987) find_first_route(): No Route headers found
>
>  7(987) loose_route(): There is no Route HF
>
>  7(987) check_self - checking if host==us: 12==14 &&  [cdshuesca.es] 
> == [10.100.100.231]
>
>  7(987) check_self - checking if port 11000 matches port 5060
>
>  7(987) SUBSCRIBE received
>
>  7(987) DEBUG: t_addifnew: msg id=1 , global msg id=0 , T on 
> entrance=0xffffffff
>
>  7(987) parse_headers: flags=-1
>
>  7(987) parse_headers: flags=60
>
>  7(987) t_lookup_request: start searching: hash=10601, isACK=0
>
>  7(987) DEBUG: RFC3261 transaction matching failed
>
>  7(987) DEBUG: t_lookup_request: no transaction found
>
>  7(987) DBG: callback type 2, id 3 entered
>
>  7(987) parse_headers: flags=1581064
>
>  7(987) parse_hfs(): Error while parsing headers
>
>  7(987) handle_subscription(): Error while parsing message header
>
>  7(987) DEBUG: t_check: msg id=1 global id=1 T start=0x402d7cd0
>
>  7(987) DEBUG: t_check: T alredy found!
>
>  7(987) parse_headers: flags=-1
>
> 7(987) parse_headers: flags=-1
>
>  7(987) check_via_address(10.100.100.232, 10.100.100.232, 0)
>
>  7(987) WARNING:vqm_resize: resize(0) called
>
>  7(987) DBG: callback type 7, id 1 entered
>
>  7(987) DEBUG: cleanup_uacs: RETR/FR timers reset
>
>  7(987) DEBUG: add_to_tail_of_timer[2]: 0x402d7d18
>
>  7(987) DEBUG: reply sent out. buf=0x80dbf58: SIP/2.0 4..., 
> shmem=0x402d9208: SIP/2.0 4
>
>  7(987) DEBUG: t_reply: finished
>
>  7(987) DEBUG:destroy_avp_list: destroing list (nil)
>
>  7(987) receive_msg: cleaning up
>
>  
>
>  
>
>  
>
> Can anyone tell me if that is a problem of the specification of XML 
> messages, or if the code in the configuration file has to be changed 
> regarding the previous version?
>
> Any comments will be of much help.
>
>  
>
> Blanca
>
>
> <http://www.lycos.es/cgi-bin/nph-bounce?pie_webcenter%7Chttp://webcenter.lycos.es/> 
>
> *¡Crea tu página web a tu estilo!*
> *             Lycos te ofrece todas las herramientas de creación web* 
> <http://www.lycos.es/cgi-bin/nph-bounce?pie_webcenter%7Chttp://webcenter.lycos.es/> 
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>  
>